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INTRODUCTION 


1.1  Background 

The  need  for  a  Discrete  Address  Beacon  System  (DABS)  was 
highlighted  in  recommendations  by  the  Department  of 
Transportation  Air  Traffic  Control  Advisory  Committee  and 
accepted  by  the  Federal  Aviation  Administration  (FAA)  to  provide 
improved  surveillance  and  ground-air  communications  in  support 
of  air  traffic  control  automation.  Development  was  reconmended 
for  an  improved  radar  beacon  interrogator/transponder  system, 
which  provides  integral  digital  data  link  communications,  as  an 
evolutionary  replacement  for  the  existing  Air  Traffic  Control 
Radar  Beacon  System  (ATCRBS).  This  development  offered  the 
potential  for  integration  of  a  new  collision  avoidance  system 
that  would  perform  automatically,  using  the  same  basic 
surveillance  and  data  link  capabilities  —  that  companion  system 
has  become  the  Automatic  Traffic  Advisory  and  Resolution  Service 
(ATARS). 

A  DABS  Experimental  Facility  (DABSEF)  was  established  at  MIT's 
Lincoln  Laboratory  to  support  DABS  concept  validation  and  system 
definition.  Testing  at  this  facility  resulted  in  the 
development  of  specifications  for  engineering  developmental 
model  DABS  sensors  and  avionics. 

Three  DABS  Engineering  Model  sensors  were  procured  and  installed 
in  the  vicinity  of  the  National  Aviation  Facilities  Experimental 
Center  (NAFEC)  for  developmental,  test  and  evaluation  purposes. 
These  DABS  Engineering  Models  were  also  interfaced  with  the 
simulated  En  Route  and  Terminal  Air  Traffic  Control  (ATC) 
systems,  at  NAFEC,  via  connections  to  the  En  Route  System 
Support  Facility  (ESSF)  and  the  Terminal  Automation  Test 
Facility  (TATF). 

1.2  DABS  Overview 


DABS  will  provide  improved  surveillance  data  reliability  and 
accuracy  over  the  present-day  secondary  surveillance  radar 
system  and  a  high  capacity,  reliable,  general  purpose 
ground-air-ground  data  link  capability.  Improvements  in 
surveillance  data  reliability  will  alleviate  certain 
deficiencies  in  the  quality  of  the  data  inherent  in  the  present 
system.  The  general  purpose,  flexible,  two-way  data  link 


communications  capability  will  support  an  extensive  variety  of 
services  necessary  for  advanced  ATC  system  automation. 
Surveillance  accuracy  improvements  in  conjunction  with  the  data 
link  capability  will  support  the  ATARS  collison  avoidance 
service.  The  ATARS  function,  which  will  be  collocated  with 
DABS,  will  give  pilots  information  about  aircraft  in  close 
proximity,  and  in  the  event  of  a  potential  collision,  will 
transmit  collision  avoidance  advisories.  The  DABS  sensors  will 
contain  the  capability  to  monitor  their  own  performance, 
allowing  for  operation  at  remote,  unmanned  sites.  DABS  will 
send  sensor  status  data  and,  when  necessary,  fault  diagnosis 
information  to  the  facilities  served.  Finally,  DABS  will  be 
fully  compatible  with  ATCRBS.  This  will  permit  DABS  to  operate 
with  the  present  ATC  system  and  will  also  enable  a  gradual, 
evolutionary  transition  into  an  ATC  environment  which  will 
benefit  fully  from  the  advanced  DABS  capabilities. 

1.3  Scope 

The  DABS  Engineering  Models  have  undergone  extensive  testing  at 
NAFEC  leading  to  the  Engineering  Requirements  (Reference  2)  for 
a  production  system.  Modifications  to  the  simulated  Terminal 
and  En  Route  ATC  facilities  at  NAFEC,  to  interface  with  DABS, 
have  also  been  made  for  developmental,  test  and  evaluation 
purposes.  This  document  describes  the  DABS  sensor  and  the 
collocated  ATARS  function  relative  to  their  interactions  with 
the  ATC  facilities  based  on  the  production  DABS  specified  in 
Reference  2.  In  addition,  a  general  description  is  provided  of 
the  Terminal  (ARTS  IIIA)  and  En  Route  ATC  facility  modifications 
necessary  for  interface  with  DABS  during  the  early  deployment 
stages.  The  descriptions  represent  the  current  DABS  design 
concepts.  The  ATC  facility  modifications  for  DABS  reflect  the 
results  of  the  R&D  soft/.’.re  development  activities  at  NAFEC,  to 
date.  The  descriptions  are  based  on  the  assumptions  of  an 
evolutionary  implementation  of  DABS  and  the  existence  of  a 
continuing,  longer  term  development  effort  to  further  upgrade 
the  ATC  systems  from  their  initial  state  as  described  herein. 

Section  2  of  this  document  discusses  the  characteristics  and  use 
of  surveillance  data;  Section  3  discusses  the  exchange  of 
messages  between  the  ATC  facility  and  an  aircraft  by  means  of 
the  DABS  air-ground  data  link  and  also  describes  some  potential 
operational  applications  in  the  Terminal  and  En  Route  ATC 
facilities;  Section  4  discusses  the  interaction  between  ATARS 
and  the  ATC  facility;  Section  5  discusses  the  information 
exchanges  between  DABS  and  the  ATC  facilities  relative  to  status 


and  control  information;  and  Section  6  describes  the  initial 
integration  of  DABS  with  the  Terminal  and  En  Route  ATC 
facilit ies. 


This  document  is  intended  to  complement  other  descriptive 
documents  pertaining  to  DABS:  Reference  1  provides  the  detailed 
formats  of  the  surveillance  and  conmunicat ions  messages 
transmitted  between  DABS  and  an  ATC  facility;  Reference  3 
provides  a  functional  description  of  the  DABS  sensor;  and 
Reference  6  provides  a  functional  description  of  ATARS. 
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SURVEILLENCE 


2 . 1  Genera 1 


DABS  will  provide  an  improved  surveillance  system  over  the 
present-day  secondary  surveillance  radar  system. 
Implementation  of  DABS  will  result  in  a  reduction  of 
synchronous  garble,  an  improvement  in  ATCRBS  reply 
degarbling,  and  a  means  of  identifying  false  ATCRBS  targets. 
The  use  of  monopulse  direction  finding  techniques  on  ATCRBS 
replies,  in  addition  to  improving  accuracy,  also  allows  the 
DABS  sensor  to  operate  at  a  significantly  reduced  ATCRBS 
interrogation  rate.  This  will  result  in  an  immediate  and 
significant  reduction  in  the  ATCRBS  interference  environment. 

DABS  Compatibility  with  ATCRBS 

DABS  is  compatible  with  ATCRBS  permitting  DABS  sensors  and 
existing  ATCRBS  sensors  to  service  both  DABS  and  present-day 
ATCRBS  transponders.  DABS  transponders  will  respond  to 
ATCRBS  interrogations  (from  present-day  ATCRBS  sensors)  with 
standard  ATCRBS  replies.  ATCRBS  transponders  will  respond  to 
ATCRBS /DABS  "All-Call"  interrogations,  from  a  DABS  sensor, 
with  standard  ATCRBS  replies.  The  "All-Call"  interrogations 
are  the  equivalent  of  the  standard  interrogations  from  an 
ATCRBS  sensor  (except  that  an  additional  pulse  is  added)  and 
will  be  transmitted  at  a  lower  interrogation  rate. 

DABS  Address 


A  fundamental  feature  of  DABS  is  the  DABS  Address.  Each  DABS 
aircraft  transponder  will  be  permanently  assigned  a  unique 
24-bit  DABS  Address  code.  The  Discrete  Address  will  permit 
each  DABS-equipped  aircraft  to  be  individually  interrogated, 
only  in  the  vicinity  of  its  known  azimuth,  with  a  "roll  call" 
DABS  interrogation.  Only  a  DABS  transponder  which  has  the 
particular  address  will  reply  to  the  "roll  call"  interro¬ 
gation.  This  reply  will  be  unambiguously  identified  with  the 
proper  aircraft. 

Sensor  Roll  Call 


In  order  to  be  discretely  interrogated  a  DABS-equipped 
aircraft  must  be  on  the  sensor's  roll  call  (i.e,,  a  file 
containing  the  DABS  Address  and  approximate 
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position  of  each  such  DABS  aircraft,  within  the  defined 
coverage  volume  of  the  sensor).  The  ATCRBS/DABS  All-Call 
interrogation  will  be  used  to  acquire  DABS  targets  which  are 
not  yet  on  the  sensor's  roll  call.  A  DABS-equipped  aircraft, 
not  on  the  sensor's  roll  call,  will  respond  to  the  All-Call 
interrogation  with  its  unique  DABS  Address  and  will  be  then 
added  to  the  roll  call. 

DABS  Transponder  Lockout 

Once  on  a  sensor's  roll  call  the  DABS-equipped  aircraft  may 
be  locked-out  from  replying  to  ATCRBS/DABS  All-Call* 
interrogations  from  any  DABS  sensor,  thus  eliminating 
unnecessary  replies.  Lockout  is  indicated  to  the  DABS 
transponder  by  setting  the  appropriate  lockout  indicator  in 
the  discretely-addressed  interrogation.  All-Call  lockout  is 
under  the  positive  control  of  the  sensor  and  thus  may  be  used 
only  where  desired.  Lockout  will  automatically  terminate  if 
an  aircraft  does  not  receive  a  discretely-addressed 
interrogation  indicating  lockout  within  approximately  16 
seconds.  Once  the  lockout  has  expired,  the  aircraft  may  be 
acquired  by  a  DABS  sensor  using  the  ATCRBS/DABS  All-Call 
interrogation.  It  should  be  noted  that  a  DABS  transponder 
which  is  not  locked-out  for  some  reason  and  is  still  on  the 
sensor's  roll  call,  will  reply  to  ATCRBS/DABS  All-Call 
interrogations  as  well  as  discretely-addressed  interrogations 
from  the  same  sensor.  In  this  case,  only  one  surveillance 
report  will  be  disseminated  from  a  given  sensor  to  the  ATC 
facility  -  that  report  will  be  based  on  the  reply  to  the 
discretely-addressed  interrogation. 

Multiple  DABS  Sensors 

In  regions  of  airspace  c  vered  by  more  than  one  DABS  sensor, 
each  DABS-equipped  aircraft  will  be  normally  on  the  roll  call 
of  at  least  two  sensors  (and  locked-out  to  any  other  DABS 
sensor  providing  coverage)  to  maintain  the  continuity  of 
surveillance  and  data  link  services  in  the  event  of  a  link 
fade  or  sensor  failure.  ATC  facilities,  to  the  extent 
possible,  and  ATARS  will  use  the  multiple  coverage  to  enable 
immediate  backup  for  surveillance  data. 


*A  DABS  transponder  which  is  locked  out  will  only  reply  to  a 
discretely-addressed  interrogation,  containing  its  DABS  Address, 
from  DABS  sensors.  It  will  still  reply  to  standard  ATCRBS 
interrogations  from  ATCRBS  sensors. 
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If,  initially,  DABS  aircraft  ia  on  the  roll  call  of  a  single 
sensor  only  (and  thereby,  usually,  locked  out  to  All-Call 
interrogations  from  other  sensors),  it  will  be  placed  on  the 
roll  call  of  an  adjacent  DABS  sensor,  with  overlapping 
coverage,  using  either  of  two  procedures: 

1.  If  the  sensors  are  connected  (netted)  with 
sensor-to-sensor  ground  links,  the  sensor  will 
coordinate  the  DABS  aircraft's  position  and  DABS  Address 
with  the  adjacent  sensor  via  a  hand-off  procedure, 
triggered  on  the  basis  of  the  aircraft's  location 
relative  to  an  adapted  sensor  map.  The  receiving  sensor 
will  use  the  data  to  place  the  DABS  aircraft  on  its  roll 
call  and  begin  transmission  of  discretely-addressed 
interrogations.  The  DABS  aircraft  will  thus  be  on  the 
roll  call  of  both  sensors.  This  procedure  will  continue 
as  the  aircraft  proceeds  from  sensor  to  sensor, 
provided  the  sensors  are  netted. 

2.  If  the  adjacent  sensors  are  not  connected 
(non-netted  configuration),  The  DABS  multi-site  protocol 
(References  3  and  4)  will  permit  a  DABS  transponder  to 
reply  to  ATCRBS/DABS  All-Call  interrogations  from  all 
other  DABS  sensors  which  do  not  have  the  respective  DABS 
aircraft  on  roll  call.  The  adjacent  sensor(s)  will  then 
acquire  the  DABS  aircraft  on  roll  call  using  ATCRBS/DABS 
All-Call  interrogations. 

Primary  Status 

Once  two  or  more  sensors  have  a  DABS  aircraft  on  their  roll 
call,  certain  ambiguities  in  sensor  operations  may  occur.  To 
avoid  this,  only  one  of  the  sensors,  at  a  time,  will  be 
designated  "Primary"*  for  a  particular  DABS  aircraft. 

Section  3.3  contains  a  discussion  of  Primary  assignment  and 
the  special  function  of  a  Primary  sensor  (among  the  special 
functions  assigned  to  the  Primary  sensor  is  the  management  of 
the  lockout  to  ATCRBS/DABS  All-Call  interrogations,  the 
readout  of  pilot-originated  downlink  messages  and  the 
uplinking  of  ATARS  traffic  advisories).  The  determination  of 
which  DABS  sensor  will  be  assigned  Primary 


*  DABS  "Primary"  status  should  not  be  confused  with  "primary 
radar".  In  this  document  the  term  "primary  radar"  is  not  used 
further . 


for  a  controlled  DABS  aircraft  will  be  made  by  Air  Traffic 
Control  (ATC)  facilities  controlling  the  aircraft  (see 
Section  5.3).  For  uncontrolled  aircraft  the  assignment  will 
be  made  by  the  DABS  sensors  on  the  basis  of  an  adapted  map. 

Sensor  Coverage 

The  volume  of  airspace  in  which  a  sensor  will  provide 
coverage  will  be  assigned,  in  each  sensor,  by  an  adapted 
coverage  map.  This  coverage  map  will  be  defined  by  a  range- 
azimuth  grid.  An  example  is  depicted  in  Figure  2-1.  Among 
other  pertinent  information  required  for  sensor  operation, 
each  cell  in  the  grid  will  contain  data  indicating  whether  or 
not  active  surveillance  is  required.  (Active  surveillance 
includes  maintaining  DABS  aircraft  on  roll  call.)  The  DABS 
sensor  will  track  targets  within  these  adapted  boundaries  of 
required  surveillance.  In  addition,  the  coverage  map  will 
define  regions  of  airspace  into  which  the  sensor  can  expand 
its  coverage  of  active  required  surveillance  if,  for  example, 
the  sensor  detects  (or  is  notified)  that  an  adjacent  sensor, 
with  overlapping  coverage,  has  failed  (refer  to  Figure  2-2). 

As  mentioned  earlier,  normally,  each  sensor's  coverage  map 
will  be  adapted  such  that  in  airspace  of  overlapping 
coverage,  an  aircraft  will  be  in  the  required  surveillance 
regions  of  at  least  two  sensors.  Thus,  for  example,  when 
overlapping  DABS  sensors  are  connected  to  an  En  Route  ATC 
facility,  the  facility  may  expect  to  receive  surveillance 
reports  on  a  given  aircraft  from  two  or  more  DABS  sensors. 

Netted/Non-Netted  Sensor  Configurations 


DABS  sensors  that  share  areas  of  overlapping  coverage  may  be 
installed  with  or  without  sensor-to-sensor  ground  data  links 
connecting  them.  Regardless  of  whether  the  sensors  are 
netted  or  non-netted,  the  Network  Management  function  in  each 
sensor  (see  Reference  3  for  a  more  detailed  description)  will 
control  the  operation  of  the  DABS  sensors  to  insure  adequate 
surveillance  and  communications  in  areas  of  common  coverage. 


FIGURE  2-1 

EXAMPLE  OF  COVERAGE  MAP  GRID  STRUCTURE 
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FIGURE  2-2 

EXAMPLE  OF  REQUIRED  AND  BACKUP  DABS  COVERAGE 


Sensor  netting,  however,  improves  the  efficiency  and 
reliability  of  DABS  and  will  be  the  normal  implementation 
mode  where  a  considerable  degree  of  sensor  overlap  occurs.* 

The  non-netted  configuration  may  be  the  permanent  implemen¬ 
tation  mode  for  some  sensors.  However,  sensors  that  are 
netted  will  have  the  provision  to  operate  in  a  non-netted 
mode  88  a  backup  in  the  event  of  a  sensor- to-sensor  link 
failure.  The  non-netted  configuration  is  thus  considered  a 
subset  of  the  netted  configuration. 

Among  the  capabilies  provided  by  the  netted  configuration  are 

1.  Management  of  DABS  transponder  lockout  (as  described 
previously)  to  assure  that  at  least  two  sensors  have 
acquired  the  same  target. 

2.  Requesting  data  from  an  adjacent  sensor  in  order  to 
assist  in  reacquiring  a  DABS  target  and  maintaining 
ATCRBS  and  DABS  tracks  -  thus  providing  surveillance 
continuity  and  for  a  DABS  target,  data  link  continuity, 
and  providing  an  immediate  source  of  backup  surveillance 
data  for  ATARS. 

3.  Coordination  of  ATARS  functions  to  assure  that  only 
one  sensor  has  responsibility  for  generation  and 
uplinking  ATARS  conflict  resolution  advisories  to  an 
aircraft. 

A.  Coordination  of  Primary  assignment  among  sensors  to 
assure  that  only  one  sensor  is  designated  Primary  for  a 
particular  uncontrolled  DABS  aircraft. 

5.  Transmission  of  sensor  status  information  to 
adjacent  sensors  in  order  that  surveillance  and  ATARS 
coverage  reconfiguration  can  be  effected  in  the  event  of 
sensor  failure. 

In  a  non-netted  configuration  some  of  these  capabilities 
cannot  be  accomplished,  or  will  be  accomplished  by  alternate 
means:  DABS  transponder  lockout  will  be  managed  by  the 

The  decision  to  connect  two  sensors  will  be  based  upon  the 
operational  and  environment  characteristics  in  the  region 
where  the  sensors  are  located  and  the  needs  of  ATARS  for  coordi¬ 
nation  between  sensors  (see  Section  4).  It  can  be  expected  that 
sensors  installed  in  areas  of  relatively  dense  traffic  will  be 
netted  with  ground  data  links. 


multi-site  protocol  mentioned  earlier;  adjacent  sensor  data 
cannot  be  obtained;  ATARS  Resolution  Advisories  (but  not 
Traffic  Advisories)  coordination  will  be  effected  by  special 
coordination  messages  transmitted  on  the  airlink;  the 
"Primary"  assignment  among  sensors,  will  rely  solely  on  the 
coverage  map  adaptation  permitting  small  regions  of 
multiple-primary  assignments  (multi-site  protocols  -  see 
Reference  4  -  will  be  used  to  effect  coordination)  in  the 
seams  between  sensors;  and  the  adjacent  sensor  failure  (or 
recovery)  information  will  be  received  only  from  the 
connected  ATC  facility  (or  other  remote  maintenance  source). 

Surveillance  Reports 

The  DABS  surveillance  reports  will  be  transmitted  over 
one-way  data  channels  dedicated  for  that  purpose.  The 
contents  of  a  surveillance  report  and  its  format  depend  on 
the  source  of  the  surveillance  data.  A  report  may  be  derived 
from  (1)  replies  from  a  DABS  transponder,  (2)  replies  from  an 
ATCRBS  transponder  or  (3)  digitized  radar  data  received  from 
a  collocated  search  radar.  In  addition,  non-target  reports 
(e.g.,  weather)  may  be  received  from  a  collocated  radar 
digitizer. 

Beacon  reports  received  from  a  DABS  sensor,  whether  derived 
from  DABS  or  ATCRBS  transponders,  will  provide  more  accurate 
position  (range  and  azimuth)  information  than  that  which  is 
provided  with  the  present-day  ATCRBS  system.  Additionally, 
the  surveillance  processing  capabilities  of  the  DABS  sensor 
provide  new  items  of  information  for  use  in  the  aircraft 
identif icaion  and  track/report  correlation  functions 
performed  by  an  ATC  facility. 

All  report  formats  whether  new  or  modified  are  based  on 
current  Comnon  Digitizer  (CD)  formats  to  maintain 
compatibility  with  existing  Gn  Route  ATC  automation. 

Surveillance-Related  Communications  Messages 

A  two-way  communications  link  will  also  connect  a  DABS  sensor 
to  an  ATC  facility  primarily  for  the  transfer  of  air-ground 
data  link  messages.  A  set  of  messages  referred  to  as 
surveillance-related  communications  messages  will  be  used  to 
maintain  surveillance  compatibility  with  the  present  ATCRBS 
system  during  the  period  of  time  when  reports  for  a 
particular  DABS-equipped  aircraft  are  received  both  from  DABS 
and  present-day  ATCRBS  sensors.  Additionally,  information 
will  be  available  via  these  messages  to  enhance  flight 
identification  capabilities.  More  detail  on  these 
surveillance-related  messages  is  provided  in  Section  2.8. 


2-8 


The  surveillance  reports  transmitted  from  the  sensor  on  the 
one-way  surveillance  link  and  the  surveillance-related 
communications  messages  transmitted  between  the  sensor  and 
the  ATC  facility  on  the  two-way  ground  communications  link 
comprise  the  DABS  surveillance  data. 

2.2  Sensor  Types 

The  basic  types  of  DABS  sensors  considered  for  implementation 
are  the  Terminal  DABS  and  the  En  Route  DABS  sensors. 

Although  alike  in  hardware  and  software  the  DABS  sites  will 
differ  in  antenna  configurations,  scan  periods  and  radar 
digitizer  interfaces. 

The  Terminal  DABS  sensors  will  have  a  single  face  antenna 
(beacon  and  search  antennas  aligned  in  azimuth)  rotating  at 
the  rate  of  12-15  rpm  (4-5  second  scan  period).  The  range  of 
these  sensors  will  be  nominally  60  nmi.  Although  it  is 
possible  under  certain  situations  to  extend  the  beacon  range 
beyond  60  nmi,  the  useful  range  for  search  will  remain 
nominally  60  nmi.  A  Terminal  DABS  sensor  will  be  interfaced, 
via  a  digital  link,  with  the  radar  digitizer  associated  with 
its  collocated  search  radar.  Depending  upon  implementation 
schedules,  the  radar  digitizer’  may  be  either  a  Moving  Target 
Detector  (MTD)  or  a  modified  Sensor  Receiver  and  Processor 
(SRAP),  referred  to  herein  as  the  Radar  Data  Acquisition 
System  (RDAS) . 

The  En  Route  DABS  sensor  will  use  a  back-to-back  antenna. 

The  front  face  will  consist  of  a  beacon  and  search  antenna; 
the  back  face,  which  will  be  aligned  180°  from  the  front 
face,  will  consist  of  a  beacon  antenna  only.  The 
back-to-back  antenna  will  rotate  at  a  rate  of  6  rpm.  This 
will  result  in  a  scan  period  of  5  seconds  for  beacon  data  and 
10  seconds  for  search  data.  The  higher  data  rate  for  beacon 
data  is  required  for  the  proper  performance  of  ATARS  in  the 
En  Route  sensor.  The  range  of  an  En  Route  DABS  sensor,  with 
its  slower  antenna  rotational  rate,  extends  to  200  nmi.  An 
En  Route  DABS  sensor  will  be  interfaced  with  the  CD  (or 
CD-2)*  associated  with  its  collocated  search  antenna. 


For  the  purpose  of  this  document,  when  reference  is  made  to  the 
CD  it  also  implies  CD-2,  except  in  the  case  of  a  joint-use  site 
where  only  the  CD- 2  will  be  used. 
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A  Terminal  DABS  sensor  will  be  connected  to  a  Terminal  ATC 
facility  and  can  also  be  linked  to  an  En  Route  ATC  facility, 
if  desired.  En  Route  DABS  sensors  will,  of  course,  be 
connected  to  En  Route  ATC  facilities.  Figure  2-3  depicts  the 
interfaces  of  the  DABS  sensors  and  respective  radar 
digitizers  with  the  ATC  facilities. 

For  joint-use  sites  an  En  Route  DABS  sensor  will  be  used  with 
back-to-back  beacon  antenna  faces,  established  to  provide 
beacon,  search  radar  and  weather  data  to  both  the  FAA  and  the 
Air  Defense  Command  (ADCOM).  In  addition,  this  type  of 
sensor  will  be  capable  of  transmitting  Mode  4  interrogations 
from  its  front  face  while  DABS  interrogations  are  being 
transmitted  from  the  back-face.  ADCOM  will  notify  the  DABS 
sensor  (via  the  CD-2  and  the  Mode  4  Controller  -  AN/GPA-124) 
that  the  front  face  of  the  en  route  antenna  is  required  for 
Mode  4  transmissions  within  a  designated  azimuth  wedge.  In 
response  the  DABS  sensor  will  dedicate  the  front-face  beacon 
antenna  to  Mode  4  operation  only  within  the  designated 
azimuths.  Beacon  and  radar  reports  received  from  the  Mode  4 
azimuth  sectors  will  be  appropriately  flagged,  by  the  sensor, 
and  transmitted  to  the  CD-2  for  dissemination  to  ADCOM.  The 
DABS  sensor  will  have  the  optional  provision  to  temporarily 
override  the  Mode  4  request  if  a  high  priority  ATARS  message 
is  pending  to  an  aircraft  in  the  requested  Mode  4  region. 
Also,  if  an  ATCRBS  report  is  detected  with  a  Mode  2  code,  the 
Mode  2  code,  in  addition  to  the  Mode  3/A  and  Mode  C  codes, 
will  be  appropriately  stored  in  an  ATCRBS  surveillance 
message  which  will  be  disseminated  to  ADCOM  (via  the  CD-2). 
The  same  report  will  be  disseminated  to  the  ATC  Facility  with 
the  ATCRBS  Surveillance  File  Number  (see  Section  2.3)  in 
place  of  the  Mode  2  code.  Figure  2-4  illustrates  a  joint-use 
En  Route  DABS  sensor. 

2.3  Sensor  Tracking 

The  DABS  sensor  will  track  all  DABS  and  ATCRBS  beacon 
targets.  A  Terminal  DABS  sensor  which  will  be  connected  to 
an  MTD  or  RDAS  will  also  track  radar-only  targets  (an  En 
Route  DABS  sensor  connected  to  a  CD  will  not  track  radar-only 
targets).  Tracking  of  DABS  beacon  targets  is  necessary  in 
order  for  the  sensor  to  predict  at  what  azimuth  to  begin 
selectively  interrogating  a  particular  DABS  target.  Tracking 
of  ATCRBS  and  radar  targets,  however,  will  provide  certain 
benefits  which  will  result  in  improved  surveillance  reporting 
and  new  items  of  information  in  addition  to  that  which  is 
available  from  the  present-day  ATCRBS  sensors. 
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An  important  item  of  information  which  will  be  provided  in 
each  tracked  ATCRBS  beacon  and  radar  report  will  be  the  DABS 
sensor's  uniquely  assigned  track  number,  designated  the 
Surveillance  File  Number  (SFN).  An  SFN  will  not  be  included 
in  a  DABS  beacon  report  because  of  the  unique  and  unambiguous 
identity  features  (24  bit  DABS  Address)  resulting  from  the 
surveillance  processing  of  DABS  beacon  replies.  However,  in 
the  case  of  ATCRBS  beacon  and  radar-only  tracking,  the  DABS 
surveillance  processing  function  will  make  decisions 
regarding  the  selection  of  the  "best"  target  report  to 
correlate  with  a  particular  sensor  track.  In  some  cases,  for 
example,  for  certain  proximate  aircraft,  the  resolving  of 
multiple  track,  multiple  report  correlation  ambiguities  will 
be  necessary  to  select  the  best  track/report  pair.  The 
track/report  correlation  function  performed  by  the  DABS 
sensor  for  ATCRBS  and  radar  data  parallels  similar 
track/report  correlation  functions  currently  performed  in  ATC 
facility  software.  Since  track/report  correlation  will  be 
performed  by  the  DABS  sensor,  the  product  of  this  function 
will  be  useful  to  aid  the  correlation  function  in  ATC 
facilities  and  the  local  ATARS. 

2.4  Noncorrelating  and  Correlating  Users 

The  users  of  the  DABS  surveillance  data  will  be  categorized 
into  two  type 8  -  noncorrelating  and  correlating.  Each  ATC 
facility,  or  user,  connected  to  a  particular  DABS  sensor  may 
be  adapted,  separately,  as  a  noncorrelating  or  correlating 
user . 

2.4.1  Noncorrelating  User 

A  noncorrelating  user  will  rely  on  the  sensor  to  peform  the 
track/report  correlation  function  and  therefore  will  do  no 
(or  very  limited)  correlation  of  its  own.  The  ARTS  IIIA 
facility  which  will  interface  with  DABS  (see  Section  6.1)  and 
ATARS  (see  Section  4.)  are  examples  of  noncorrelating  users. 
The  SFN  in  the  surveillance  report  will  be  the  chief  means  of 
conveying  the  results  of  the  correlation  for  non-DABS 
tracks.  If  an  ATCRBS  beacon  or  search  report  cannot  be 
correlated,  the  SFN  will  not  be  contained  in  the  transmitted 
surveillance  report.  This  uncorrelated  report  will  not  be 
utilized  by  the  noncorrelated  user  (except,  possibly,  for 
display  purposes  in  an  ATC  facility).  Since  the  SFN  will  be 
critical  to  the  noncorrelating  user,  the  sensor  may  under 
some  circ instances  delay  slightly  the  dissemination  of 
certain  ATCRBS  or  search  reports  until  a  "best"  track/report 
correlation  can  be  determined  and  the  SFN  included.  For  the 
ARTS  IIIA  interface  with  DABS,  this  slight  delay  will  not 
cause  the  overall  time,  from  the  time  the  particular  aircraft 
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is  in  Che  antenna  beam  to  the  time  it  will  be  displayed  to 
the  controller,  to  exceed  current  ARTS  IIIA  response  times 
(since  the  correlation  function  will  be  performed  by  the  DABS 
sensor  it  will  not  have  to  be  repeated  by  the  noncorrelating 
user). 

There  are  some  special  processing  rules  which  affect  the  dis¬ 
semination  of  MTD  and  RDAS  originated  radar-only  reports. 
These  rules  are  described  in  Section  2. 7. 5. 2. 4. 

2.4.2  Correlating  User 

A  correlating  ATC  facility  will  perform  all  track/report 
correlation  functions,  as  is  presently  done  in  the 
operational  En  Route  and  ARTS  IIIA  facilities,  independent 
from  the  sensor.  While  a  correlating  ATC  facility  may  use 
the  SFN  for  some  purposes,  it  will  not  solely  rely  on  it  for 
correlation.  The  sensor  will  not  delay  dissemination  for  the 
particular  reasons  cited  for  the  noncorrelating  user. 

Rather,  each  report  will  be  disseminated  within  the  maximum 
delay  time  specified  for  the  sensor  (Section  2.5),  whether  or 
not  it  has  correlated  with  a  sensor  track.  The  En  Route  ATC 
System  which  will  interface  with  DABS  (see  Section  6.2)  will 
be  a  correlating  user. 

2.4.3  DABS  Beacon  Reports 

It  should  be  noted  that  the  distinction  between  correlating 
and  noncorrelating  user  will  not  apply  to  DABS  beacon 
reports,  which  contain  the  DABS  Address. 

2.5  Reporting  Delay 

The  maximum  allowable  time  that  surveillance  reports  may  be 
delayed  by  the  sensor  for  transmission  to  an  ATC  facility 
depends  on  whether  the  receiving  facility  is  a  correlating  or 
noncorrelating  user  (see  Section  2.4).  In  the  case  of  a 
correlating  user,  surveillance  reports  will  be  ready  for 
transmission  not  later  than  3/32  of  an  antenna  scan  period 
(3/16  of  the  effective  scan  period*  for  any  back-to-back 
antenna)  after  the  target  report  has  been  detected.  For  a 
4-second  rotator  with  a  single  face  antenna,  this  maximum 
delay  will  be  3/8  second;  for  a  back-to-back  antenna  mounted 
on  a  10-second  rotator,  the  maximum  delay  will  be  15/16 

The  effective  scan  period  for  a  back-to-back  antenna  is  con¬ 
sidered,  herein,  as  one  half  the  period  of  the  antenna  shaft 
rotation.  For  example,  a  back-to-back  beacon  antenna  mounted 
on  a  shaft  rotating  with  a  10  second  period  will  have  an 
effective  beacon  scan  period  of  5  seconds. 
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second.  In  Che  case  of  a  noncorrelating  user,  Che  maximum 
allowable  delay  for  surveillance  data  within  10  miles  of  Che 
sensor  may  be  greater  to  allow  for  resolution  of  certain 
multiple  report/multiple  track  correlation  possibilities. 

For  example,  this  may  occur  for  some  reports  in  regions  of 
dense,  nondiscrete  Mode  3/A  beacon  traffic.  Surveillance 
reports  which  have  not  correlated  with  a  track  within  the 
maximum  allowable  time  consistent  with  each  user  type 
(correlating  or  noncorrelating)  will  be  transmitted  to  the 
respective  user  as  "uncorrelated"  (i.e.,  the  report  will  not 
contain  an  SFN).  The  delay  time  will  be  reported  in  the  Time 
in  Storage  field  of  the  surveillance  message  (quantized  to 
1/8  second  as  in  the  existing  CD  message). 

2.6  Data  Dissemination 


A  DABS  sensor  will  not  necessarily  transmit  all  of  its 
aircraft  reports  to  each  ATC  facility  linked  to  it.  Instead, 
it  will  use  a  data  dissemination  map  to  transmit  reports  on 
only  those  aircraft  located  within  the  area  of  interest  to 
each  ATC  facility  connected,  thereby  reducing  the  volume  of 
unnecessary  reports  for  the  facility  to  process.  Thus,  each 
data  dissemination  map,  corresponding  to  the  different 
surveillance  needs  of  each  ATC  facility,  may  be  different  for 
each  ATC  facility.  The  dissemination  decision  will  be  based 
on  a  simple  criterion  of  range,  azimuth  and  altitude.  Of 
course,  the  report  must  also  have  been  derived  from  within 
the  sensor's  region  of  required  surveillance.  This 
dissemination  map  will  be  fixed  for  each  ATC  facility  but  may 
change  as  part  of  backup  operations  if  one  (or  more)  of  the 
connected  ATC  facilities  fails.  For  example,  when  a  sensor 
is  notified  of  an  ATC  facility  failure,  (e.g.,  via  an  ATC 
Failure/Recovery  Message  received  on  the  Communications  link, 
see  Section  3.2.4)  the  dissemination  map  will  be  reconfigured 
to  a  new  dissemination  map  based  on  the  remaining  connected 
ATC  facilities  (refer  to  Figure  2-5). 

An  additional  dissemination  feature  will  be  available  for  a 
sensor  configured  with  a  back-to-back  antenna.  The  option, 
set  in  adaptation,  will  be  provided  to  disseminate 
surveillance  reports  derived  from  only  the  front  face  of  the 
back-to-back  antenna.  This  permits  surveillance  report 
dissemination  at  a  10  (or  12)  second  scan  rate  until  such 
time  as  the  En  Route  ATC  facility  and  telephone  line  capacity 
is  available  to  handle  the  5  (or  6)  second  surveillance 
update  rate. 
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DABS 

SEPARATE  DISSEMINATION  TO  ATC  A  AND  ATC  B 


DISSEMINATION  TO  ATC  B,  FOR  BACKUP,  AFTER 
ATC  A  FAILS 

FIGURE  2-5 

EXAMPLE  OF  DISSEMINATION  MAP  CHANGE  AFTER 
ATC  FACILITY  FAILURE 

2-if) 


2.7  Surveillance  Reports 


2.7.1  Surveillance  Report  Types 

Surveillance  reports  transmitted  on  the  surveillance  link 
will  utilize  formats  and  coding  which  are  modified  versions 
of  those  presently  used  for  CD  messages.  The  surveillance 
report  types  are: 

1.  Beacon  Reports:  ATCRBS  and  DABS 

2.  Radar  Reports,  based  on  radar  targets,  received  from 
a  collocated  Radar  Digitizer  (CD,  MTD  or  RDAS):  CD 
Search,  MTD  Search  and  RDAS  Search  Reports,  respectively. 

3.  Radar  Substitution  Reports:  When  a  radar  report 
correlates  with  a  beacon  track  and  beacon  replies  for 
the  track  from  the  current  scan  are  missing,  a  Radar 
Substitution  Report  will  be  transmitted.  This  report 
will  contain  the  identity  of  the  beacon  track  in 
addition  to  the  search  data.  Depending  on  whether  the 
radar  report  correlated  with  a  DABS  track  or  an  ATCRBS 
track,  the  report  types  are  DABS  Radar  Substitution  and 
ATCRBS  Radar  Substitution,  respectively. 

A.  Non-target  Reports 

a.  Derived  from  the  CD:  Strobe,  Map  (including 
weather),  CD  Status,  and  Fixed  Search  RTQC  Target 

b.  Derived  from  either  the  MTD  or  RDAS:  Weather 
message  in  the  format  of  the  CD  Weather  message. 

The  beacon  reports,  the  Radar  Substitution  reports,  the  MTD 
Search  reports  and  the  RDAS  Search  reports  will  have  a  long 
(91-bit)  format,  whereas  all  the  others  will  have  a  short 
(52-bit)  format.  All  of  the  non-target  reports  input  to  DABS 
will  be  transmitted  to  the  ATC  facility  without  being  altered 
by  processing  in  the  DABS  sensor.  The  processing  and  output 
of  search  target  reports  by  the  DABS  sensor  is  described  in 
Section  2.7.5. 

The  following  sections  describe  the  target  reports 
disseminated  by  DABS.  Also,  Reference  1  presents  complete 
formats  and  detailed  field  definitions  for  the  various  types 
of  surveillance  messages. 
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2.7.2  Common  Surveillance  Data  Elements  in  Beacon  Reports 


Beacon  reports,  whether  based  on  DABS  or  ATCRBS  replies,  will 
contain  basic  surveillance  data  in  common.  Reflecting  the 
improved  accuracy  of  the  DABS  sensor,  15  bits  of  slant  range 
information  (to  a  precision  of  0.0078  nmi  or  approximately  50 
feet)  and  13  bits  of  azimuth  (to  0.044  degree)  will  be 
provided.  Range  and  azimuth  data  are  raw  measurements  which 
will  not  be  smoothed  by  the  sensor  tracker.  Altitude  data 
will  be  provided  as  in  the  present  day  ATCRBS:  converted 
from  Mode  C  data,  quantized  to  100  feet  and  not  pressure 
corrected.  Certain  target  identification  data  will  always  be 
present:  the  24-bit  DABS  Address  in  a  DABS  report  and  the 
12-bit  Mode  3/A  Code  in  an  ATCRBS  report.  Storage  delay  will 
be  reported  in  the  message  Time-in-Storage  field  (quantized 
to  1/8  second  as  in  the  present  CD  surveillance  message). 
Other  information  included  in  the  various  types  of 
surveillance  reports  is  provided  in  the  subsection  below. 

2.7.3  Beacon  Reports  from  ATCRBS-Equipped  Aircraft 

In  addition  to  data  pertaining  to  range,  azimuth,  altitude 
(when  Mode  C  replies  are  available)  and  storage  time,  an 
ATCRBS  aircraft  report  from  a  DABS  sensor  will  include 
several  additional  data  fields  that  are  the  same  as  those  in 
a  present-day  beacon  report  from  the  CD  and  some  new  ones. 

The  data  fields  contained  in  the  present-day  reports  include 
indicator  bits  (Test,  Mode  3/A,  Mode  C,  SPI  (Ident),  Radar 
Reinforcement,  Emergency-Code  7700,  Radio  Failure-Code  7600, 
and  FAA)  and  the  12-bit  Mode  3/ A  code  (when  available  as 
indicated  by  the  Mode  3/A  bit).  The  Test  bit  will  be  set 
when  the  report  correlated  with  a  stationary  test  track 
(i.e.,  based  on  the  adapted  location  of  the  Calibration 
Performance  Monitoring  Equipment  -  CPME).  As  with  the 
present  beacon  formats,  the  presence  of  Radar  Reinforcement 
will  indicate  that  a  radar  report  has  correlated  with  a 
beacon  report  and  that  the  radar  report  has  been  suppressed. 
The  new  ATCRBS  report  data  fields  will  include  the  ATCRBS 
Surveillance  File  Number,  Confidence,  Code-in-Transition, 
False  Target,  Radar  and  Data  Relay.  Each  of  these  fields  are 
discussed  in  the  following  paragraphs. 

The  ATCRBS  Surveillance  File  Number  (SFN),  as  mentioned 
earlier  is  the  sensor-assigned  number  used  within  the  DABS 
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sensor  software  to  identify  a  particular  aircraft  track.  The 
presence  of  a  nonzero  value  in  this  field  will  indicate  that 
the  ATCRBS  replies  being  reported  have  been  successfully 
correlated  with  an  existing  track.  The  presence  of  all  zeros 
will  mean  the  report  has  not  correlated  with  a  track.  The 
number  will  provide  a  reference  track  number  for  a  given 
aircraft,  which  will  be  unique  for  the  sensor  -  therefore, 
two  tracks  will  not  have  the  same  number  at  a  given  time 
within  a  single  sensor.  The  assignment  of  these  numbers  will 
not  be  coordinated  among  sensors.  Thus,  the  same  aircraft 
reported  by  two  sensors  will  have  independently  chosen  SFNs. 
Twelve  (12)  bits  are  available,  so  that  a  duplicate  on 
simultaneously  active  tracks  will  not  occur.  A  sensor  track 
which  does  not  correlate  with  any  report  for  an  adaptable 
number  of  scans  will  be  dropped  and  its  SFN  will  be  placed  at 
the  end  of  the  list  of  SFNs  available  for  reassignment. 

Confidence  is  a  1-bit  indicator  which  will  denote  whether  or 
not  the  target-to-track  correlation  has  been  performed  with 
high  or  low  confidence;  specifically,  whether  or  not 
correlation  was  successful  using  the  smallest  range-azimuth 
correlation  box.  This  indicator  will  have  significance  only 
when  a  correlation  is  reported,  as  shown  by  a  nonzero  SFN. 

The  indicator  will  be  useful  in  refining  the  track/report 
correlation  processing  in  the  ATC  facility  software. 

Code-in- Transition  is  another  1-bit  tag,  which,  when  set, 
will  indicate  that  the  report  is  based  on  Mode  3/A  replies, 
of  which  the  code  value  did  not  match  that  of  the  track's 
stored  Mode  3/A  code  although  all  other  requirements  for 
correlation  were  met  (the  report  and  the  track  are  therefore 
considered  to  be  correlated).  The  Mode  3/A  code  of  the 
presently  corelated  target  report  will  be  transmitted.  If 
the  same  (new)  Mode  3/A  code  correlates  for  three  successive 
scans,  the  code  of  the  stored  track  will  be  changed  to  this 
new  code  and  the  Code-in-Transition  indicator  reset  to  zero. 
The  Code-in-Transition  indicator  can  provide  a  signal  that 
the  pilot  is  changing  the  transponder's  Mode  3/A  code. 

False  Target  is  a  1-bit  tag  which  will  indicate  when  a  report 
has  been  identified  as  being  caused  by  a  reflection  from  a 
building  or  other  terrain  feature.  A  map  of  known  reflectors 
will  be  maintained  in  sensor  storage  for  this  purpose.  The 
"false  target"  decision  will  be  based  upon  an  examination  of 
the  reflection  path  geometries  resulting  from  a  true  target 


and  the  known  position  of  a  reflector.  This  information  will 
be  useful  in  eliminating  reports,  or  giving  low  priority  to 
reports  for  the  track/report  correlation  function  in  ATC 
sof  tware . 

A  format  control  bit  designated  "Radar",  will  be  provided  to 
denote  whether  the  message  is  an  ATCRBS  beacon  report  or  a 
message  containing  search  data  (including  Radar  Substitution). 
Section  2.7.5  describes  the  message  when  "Radar"  is  indicated. 

Data  Relay  is  a  one-bit  indicator  which,  when  set,  will 
indicate  that  the  surveillance  report  has  originated  with  a 
sensor  not  connected  to  this  ATC  facility  (i.e.,  the  remote 
sensor)  and  should  be  used  with  consideration  of  some  of  the 
restrictions  noted  below.  This  surveillance  data  may  be 
relayed  under  certain  conditions  when  a  sensor- to-sensor  data 
link  connects  the  originating  (remote)  sensor  to  the  relaying 
sensor  (the  local  sensor  connected  to  the  ATC  facility 
receiving  the  reports  is  the  relaying  sensor)  and  the  Relay 
Mode  option*  is  selected,  under  parameter  control,  by  the 
sensor  (see  Reference  2).  The  relayed  ATCRBS  surveillance 
report  received  by  the  ATC  facility  will  be  similar  to  a 
report  originating  with  the  relaying  sensor  in  its  principal 
data  fields;  range  and  azimuth  however  will  be  converted  to 
local  (relaying)  sensor  coordinates  and  the  position 
estimated  for  the  time  of  measurement  in  the  local  sensor; 

Mode  3/A  code  and  Mode  C  altitude  will  not  be  affected;  SFN 
will  be  given  for  the  local  sensor.  Other  data  fields  will 
be  unaffected,  except  that  Radar  Substitution,  Confidence, 
Code-in-Transition  and  False  Target  will  not  be  used.  It 
should  be  noted  that  neither  ATCRBS  report  data  without  Mode 
C  nor  Search  data  will  ever  be  relayed.  There  will  be  no 
indication  in  the  relayed  surveillance  report  identifying  the 
originating  sensor. 

2.7.4  Beacon  Reports  from  DABS-Equipped  Aircraft 

As  mentioned  in  Section  2.7.2,  DABS  reports  include  range, 
azimuth,  storage  time  and  altitude  data  as  included  in  ATCRBS 


Relaying  of  data  under  this  option  should  not  be  confused  with 
the  use  of  surveillance  data  from  an  adjacent  sensor  for  ATARS 
purposes;  that  is  a  different  function  (see  Reference  6). 
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reports.  Both  altitude  and  the  DABS  Address  will  be  present 
in  each  DABS  report  whenever  the  aircraft  is  on  roll  call, 
the  normal  surveillance  mode.  During  acquisition,  however, 
replies  from  a  DABS  transponder  may  consist  of  only  All-Call 
replies,  which  do  not  provide  altitude  (and  therefore  the 
Mode  C  bit  will  not  be  set).  Under  normal  conditions  this 
situation  should  not  last  for  more  than  one  or  two  scans. 

The  presence  of  altitude  will  be  indicated  by  a  1-bit  "Mode 
C"  tag,  as  in  ATCRBS  reports.  It  should  be  noted,  however, 
that  the  setting  of  the  Mode  C  bit  does  not  always  insure 
that  a  valid  altitude  is  present.  In  the  case  where  the 
altitude  encoder  is  turned  off  (failed),  an  all  zero 
(incorrect)  altitude  will  result  but  the  Mode  C  bit  will  be 
set. 

DABS  reports  also  include  SPI,  Codes  7700,  7600,  Radar 
Reinforcement,  Radar  and  Data  Relay  fields  and  are  the  same 
as  those  designated  for  ATCRBS.  The  new  types  of  information 
provided  in  a  DABS  report  are  the  DABS  Address,  P/S 
(Primary/Secondary)  Status  and  Alert.  These  are  discussed  in 
the  following  paragraphs. 

DABS  Address  is  the  24-bit  code  that  will  uniquely  identify 
each  aircraft  equipped  with  a  DABS  transponder.  Since  this 
DABS  Address  will  provide  a  very  high  confidence  for 
correlation  of  replies  to  tracks,  no  other  identification 
data  will  be  needed  or  included  (such  as  the  Mode  3/A  code  or 
SFN).  Provision  will  be  made  for  handling  the  extremely  low 
probability  error  condition  of  two  targets  having  the  same 
DABS  Address;  this  is  discussed  in  Section  2.8.3. 

P/S  (Primary/ Secondary)  Status  (see  Section  5.3)  will  be 
designated  in  a  one-bit  indicator.  The  indicator  will  be 
used  to  assure  that  a  data  link  connectivity  is  being 
maintained  between  the  ATC  facility  and  the  respective 
DABS-equipped  aircraft  the  facility  is  controlling. 

Alert  is  a  1-bit  indicator  signifying  that  a  pilot  has 
changed  the  ATCRBS  Mode  3/A  code  of  the  transponder  (see 
Section  3. 3.4.4).  (When  codes  7600  or  7700  exist,  the  Alert 
bit  will  be  set  redundantly  with  the  Code  7600  or  Code  7700 
indicator).  The  corresponding  ATCRBS  code  received  by  the 
sensor  from  the  transponder  will  be  transmitted  to  the  ATC 
facility  on  the  ground  communications  link  in  an  ATCRBS  ID 
Code  Message  (see  Section  2.8).  When  a  DABS  beacon  report  is 
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received  by  the  ATC  facility  with  the  Alert  bit  set,  it  will 
be  a  general  indication  that  an  ATCRBS  ID  Code  Message  will 
be  received  on  the  ground  communications  link  providing  the 
new  (changed)  setting  of  the  ATCRBS  Mode  3/A  code  for  the 
respective  DABS-equipped  aircraft. 

For  a  DABS  beacon  report  with  the  Data  Relay  bit  set,  the 
various  data  fields  are  to  be  interpreted  as  for  an  ATCRBS 
data  relay  report;  the  following  fields  which  will  be  unique 
to  DABS,  however,  will  not  be  used:  P/S  Status  and  Alert  . 

2.7.5  Radar  Reports 

Radar  (Search)  reports  from  a  DABS  sensor  may  originate  from 
one  of  the  following  types  of  collocated  radar  digitizer: 

CD,  MTD  or  RDAS.  Different  kinds  of  surveillance  messages 
derived  from  radar  data  will  be  transmitted  to  the  ATC 
facility  depending  upon  (1)  the  originating  radar  digitizer, 
(2)  whether  radar-only  tracking  will  be  performed  for  the 
data  from  the  particular  digitizer  and  (3)  the  extent  to 
which  the  radar  reports  correlate  with  tracks  maintained  in 
the  sensor.  The  following  general  rules  are  summarized: 

1.  When  the  sensor  correlates  the  Radar  report  with 
either  a  DABS  or  an  ATCRBS  beacon  report,  the  beacon 
report  will  be  tagged  as  "Radar  Reinforced"  and  the 
radar  measurement  will  not  be  separately  reported  (only 
the  range  and  azimuth  measurement  of  the  beacon  report 
will  be  used). 

2.  When  the  Radar  report  unambiguously  correlates  with 
a  beacon  track  and  the  beacon  replies  from  the  current 
scan  are  missing,  the  radar  data  will  be  reported  in  a 
"Radar  Substitution'  report.  In  a  Radar  Substitution 
report  the  radar  data  will  be  reported  using  a  modified 
91-bit  ATCRBS  or  DABS  beacon  format  (depending  upon  the 
particular  track  type)  rather  than  the  "Search"  report 
format  so  that  its  correlation  with  the  respective 
sensor  track  can  be  indicated.  The  range  and  azimuth 
measurement  of  the  radar  report  will  be  transmitted. 

3.  When  a  Radar  report  correlates  with  a  radar-only 
track  (in  the  case  of  MTD  or  RDAS  originated  reports)  it 
will  send  a  "Radar-only"  report  including  the  track's 
unique  SFN.  In  this  case  the  correlated  Radar-only 
report  will  be  sent  in  a  modified  91-bit  beacon  format. 
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4.  When  a  Radar  report  does  not  correlate  with  either  a 
beacon  or  radar-only  track  or  when  the  Radar  report 
originates  from  a  radar  digitizer  type  for  which  no 
radar-only  tracking  will  be  done  (e.g.,  CD),  it  will  be 
sent  as  a  Radar-only  report  without  a  track  nunber. 

This  uncorrelated  Radar-only  report  will  either  be  sent 
in  a  52-bit  CD  Search  format  or  a  91 -bit  format 
depending  upon  the  originating  radar  digitizer. 

Surveillance  messages  transmitted  in  the  91-bit  format  which 
are  based  on  radar  reports  will  be  distinguished  from  beacon 
reports  by  examination  of  a  1-bit  Radar  indicator.  If  the 
Radar  indicator  is  set,  another  field  in  the  message  is 
examined  to  determine  whether  the  message  is  based  on  radar 
data  originating  from  the  MTD  or  RDAS  and  whether  the  message 
is  Radar  Substitution  or  Radar-only. 

2. 7. 5.1  Collimation  Correction 


Each  radar  report  will  be  altered,  if  necessary,  by  the 
addition  of  a  collimation  correction  to  the  value  of  search 
azimuth  and/or  range  received  from  the  radar  digitizer.  The 
collimation  correction  is  intended  to  eliminate  bias  errors 
between  the  radar  and  the  beacon  antennas.  Collimation 
correction  values  will  be  computed  and  applied  dynamically  in 
a  manner  analogous  to  the  correction  presently  performed  in 
the  En  Route  ATC  System.  This  capability  relieves  the  ATC 
facilities  from  performing  this  function. 

2. 7. 5. 2  Processing  and  Output  of  Radar  Data 

The  particular  differences  of  processing  and  output  of  radar 
data  by  DABS,  depending  upon  the  type  of  collocated  radar 
digitizer,  are  summarized  below. 

2. 7, 5. 2.1  Common  Digitizer  (CD) 

A  DABS  sensor  interfaced  with  a  CD  will  not  track  radar-only 
targets.  Therefore,  any  radar  reports  which  do  not  correlate 
with  beacon  tracks  will  be  sent  in  a  format  identical  to  the 
52-bit  CD  Search  Message.  However,  the  Time-in-Storage  of 
the  radar  report  received  from  the  CD  is  adjusted,  prior  to 
transmission  to  the  ATC  facility  to  reflect  the  additional 
time  elapsed  while  the  report  is  in  the  DABS  sensor.  Except 
for  the  collimation  correction  and  the  addition  of  the  DABS 
sensor  time- in- storage ,  che  message  is  transmitted  as 
received  from  the  CD,  unaltered. 


A  Radar  Substitution  report,  however,  will  be  sent  in  the 
91-bit  beacon  format,  DABS  or  ATCRBS.  The  appropriate  fields 
in  the  message  will  designate  it  uniquely  as  a  Radar 
Substitution  report  based  on  a  radar  report  from  the  CD.  The 
message  will  contain  the  DABS  Address  or  the  Mode  3/A  code 
and  SFN  of  the  beacon  track  with  which  it  correlated, 
depending  upon  whether  correlation  was  with  a  DABS  or  ATCRBS 
track,  respectively.  When  cc -relation  is  with  an  ATCRBS 
track,  the  Mode  3/A  code  of  the  last  ATCRBS  beacon  report  to 
correlate  with  the  track  will  be  sent  along  with  the  SFN. 
Time-in-Storage  will  be  adjusted  as  noted  in  the  previous 
paragraph.  Additionally,  the  Run  Length  of  the  original 
radar  report  will  be  retained  and  sent  in  the  Radar 
Substitution  report,  replacing  part  of  the  Mode  C  field, 
which,  of  course,  cannot  be  used  for  radar  data.  Other 
fields  of  the  91-bit  format  pertaining  to  beacon  data  will 
not  be  used.  It  should  be  noted  that  if  the  sensor  track 
fails  to  correlate  further  with  beacon  data,  Radar  Substi¬ 
tution  reports  will  be  transmitted  only  up  to  a  maximum 
number  of  (site-adaptable)  scans  before  the  respective  track 
is  dropped.  Subsequent  reports  will  be  sent  in  the  52-bit 
search  report  format. 

2. 7. 5. 2. 2  Moving  Target  Detector (  MTD) 

In  addition  to  tracking  beacon  targets,  a  Terminal  DABS  sensor 
will  track  radar-only  targets  when  the  radar  reports  originate 
from  an  MTD.  The  resulting  MTD  Raaar-only  Messages  will  be 
sent  in  a  91-bit  format  and  contain  some  data  elements 
different  than  what  is  included  in  the  52-bit  CD  search 
message.  Fields  in  common  will  be  Range  and  Azimuth  (except 
that  the  MTD  message  contains  a  15  bit  range  with  a  least 
significant  bit  of  0.0078  nmi  and  a  13-bit  azimuth  with  a  least 
significant  bit  of  0.044  degrees)  and  Time-in-Storage.  The  MTD 
message,  however,  will  not  contain  a  Run  Length  field.  The  new 
data  elements  in  the  MTD  Radar-only  message  will  be:  SFN, 
Doppler  #1,  Doppler  #2,  Quality,  MTD  Confidence,  False  Target 
Flag  and  Ground  Traffic  Indicator. 

The  SFN  for  a  radar-only  track  will  be  identical  to  that  of 
the  ATCRBS  message.  All  sensor  tracks,  however,  whether 
beacon  or  MTD  Radar-only,  will  be  contained  in  one  file 
resulting  in  a  single  set  of  nonduplicate  SFN's  for  a  given 
sensor.  An  MTD  Radar-only  message  which  has  not  correlated 
with  any  track  will  have  an  all-zero  SFN. 


The  Doppler  #1  and  Doppler  #2  fields  will  express  the 
interpolated  values  of  the  doppler  velocities  measured  at  the 
low  and  the  high  PRF  of  the  radar,  respectively. 

Quality  is  a  2-bit  field  which  will  denote  a  figure  of  merit 
for  the  reported  azimuth  value. 

MTD  Confidence  is  a  4-bit  field  which  will  provide  an 
estimate,  by  the  MTD,  that  the  measurement  represents  a  real 
aircraft  rather  than  a  false  alarm.  Each  bit  will  give  a 
confidence  estimate  (l=high,  0=low)  in  a  different  category. 

False  Target  is  a  one-bit  flag  which  will  indicate  that  the 
report  has  been  generated  from  search  returns  that  are  close 
to  the  sensor  and  have  velocities  less  than  a  site-adaptable 
parameter. 

Ground  Traffic  is  a  one-bit  flag  which  will  denote  that  the 
report  has  been  generated  in  regions  of  known  ground  traffic 
(e.g.,  cars)  adapted  in  the  MTD. 

The  Quality,  Confidence,  False  Target  and  Ground  Traffic 
fields  will  be  useful  to  provide  a  controller  with  additional 
display  filtering  options  for  radar-only  reports. 

Radar  Substitution  reports  originating  with  radar  data  from 
the  MTD  will  be  uniquely  identified  as  such  and  will  be 
otherwise  identical  to  Radar  Substitution  reports  generated 
on  the  basis  of  CD  radar  reports,  with  the  following 
exceptions:  The  Quality  field  will  be  included  (as  described 
previously)  and  there  will  be  no  Run  Length  field.  In 
addition,  a  beacon  track  from  which  only  Radar  Substitution 
reports  have  been  generated  for  a  site-adaptable  nunber  of 
scans  will  be  dropped  and  replaced  with  a  radar-only  track. 

2. 7. 5. 2. 3  Radar  Data  Acquisition  System  (RDAS) 

A  Terminal  DABS  sensor  will  also  track  radar-only  targets 
when  the  radar  reports  originate  from  an  RDAS.  The  resulting 
RDAS  Radar-only  Messages  sent  from  the  DABS  sensor  to  the  ATC 
facility  will  be  sent  in  a  91-bit  format  and  will  be 
identical  to  the  MTD  radar-only  format  with  the  following 
exceptions:  Quality  will  be  reported  in  a  4-bit  field, 
unaltered  as  received  from  the  RDAS  (RDAS  Quality  will  be 
derived  from  the  radar  run  length);  and  the  RDAS  report  will 
not  contain  the  Doppler  #1,  Doppler  #2,  Confidence  and  Ground 
Traffic  fields. 


2. 7. 5. 2. 4  Special  Dissemination  Rules  for  MTD  and  RDAS 
Radar-Only  Reports 


Special  rules  will  apply  to  the  dissemination  of  Radar-only 
reports  from  the  MTD  (or  RDAS)  to  noncorrelating  ATC 
facilities.  The  purpose  of  these  rules  is  to  minimize 
sending  radar-only  reports  which  do  not  represent  real 
aircraft.  Restrictions  on  the  dissemination  of  MTD  (or  RDAS) 
radar-only  data  to  noncorrelating  ATC  facilities  will  be 
applied  in  accordance  with  one  of  the  following  options, 
determined  by  site  adaptation: 

1.  Uncorrelated  reports  will  not  be  disseminated, 

2.  Uncorrelated  reports  will  not  be  disseminated  unless 
Quality  and  Confidence  values  meet  site  adaptable 
thresholds , 

3.  The  second  report  of  each  pair  used  by  the  sensor  to 
initiate  a  new  radar-only  track  will  be  disseminated 
provided  its  Quality  and  Confidence  values  meet 
site-adaptable  thresholds.  Subsequent  reports  which 
correlate  with  the  track  will  also  be  disseminated  on 
the  basis  of  these  thresholds  until  a  site-adaptable 
number  of  correlations  have  occured. 

The  definition  of  uncorrelated  radar  reports  is  also  modified 
slightly  for  noncorrelating  users,  affecting  the  value  of  the 
SFN  fields.  An  MTD  (or  RDAS)  radar  report  that  correlates 
with  an  existing  radar-only  track  will  be  disseminated  as 
correlating  data  (i.e.,  the  report  will  contain  an  SFN)  only 
after  the  track  has  been  declared  "mature"  by  the  sensor. 
(Maturity  is  defined  as  the  occurrence  of  correlation  for  a 
site-adaptable  number  of  scans).  Prior  to  maturity,  within 
the  constraints  of  the  aforementioned  options,  the  sensor 
will  send  such  a  correlated  MTD  (or  RDAS)  radar  report  to  a 
noncorrelating  user  with  an  all-zero  value  in  its  SFN  fields. 

In  addition,  dissemination  of  uncorrelated  MTD  radar  reports 
will  be  restricted  by  a  special  site-adaptable  coverage  map. 

The  ATC  facility  will  have  the  capability  to  display  to  the 
Controller,  when  desired,  uncorrelated  radar-only  reports. 

The  option  to  delay  the  insertion  of  an  SFN  into  the 
radar-only  report  will  prevent  the  noncorrelating  ATC 
facility  from  starting  a  track  until  sufficient  confidence 


has  been  gained  chat  the  track  represents  a  real  aircraft. 
This,  in  turn,  will  reduce  the  false  track  load  in  the  ATC 
facility  without  compromising  the  ability  to  display  the 
targets  (as  uncorrelated)  to  the  controller.  Further,  in 
this  regard,  the  DABS  sensor  will  only  be  permitted  to 
process  an  adaptable,  maximum  number  of  radar-only  tracks. 

If  the  maximum  radar  track  capacity  is  reached,  the 
additional  radar-only  reports  will  be  transmitted  to  the  ATC 
facility  as  uncorrelated. 

2. 7. 5. 2. 5  MTD  and  RDAS  Interface  Without  Radar-Only  Tracking 

When  interfaced  with  the  MTD  or  RDAS,  the  Terminal  DABS 
sensor  will  have  the  provision  of  handling  search  reports 
similar  to  the  way  described  in  Section  2. 7. 5. 2.1  for  the  CD 
(i.e.,  without  radar-only  tracking). 

2.8  Surveillance-Related  Communications  Messages 

Included  in  the  messages  transmitted  on  the  two-way  ground 
link  between  DABS  and  an  ATC  facility  are  a  class  of  messages 
designated  "Surveillance-Related  Communications  Messages". 

The  purpose  of  these  messages  is  to  aid  the  survillance  and 
aircraft  identification  functions  performed  by  the  ATC 
facility.  These  messages  are  the  ATCRBS  ID  Request,  the 
ATCRBS  ID  Code  Message,  the  Track  Alert  Message  and 
surveillance-related  applications  of  the  Request  for  Downlink 
Data  and  its  corresponding  Tactical  Downlink  Message 
containing  requested  aircraft  identification  data.  The  use 
of  these  messages  for  surveillance  purposes  is  discussed  in 
the  following  paragraphs. 

2.8.1  ATCRBS  ID  Code 

The  ATCRBS  ID  Code  Message  (see  Section  3. 3. A. 4)  is  a 
DABS-to-ATC  facility  message  which  will  communicate  the 
ATCRBS  Mode  3/A  Code  setting  of  the  respective  DABS 
transponder  to  the  ATC  facility.  The  message  is  generated 
either  as  a  result  of  an  ATCRBS  ID  Request  (see  Section 
3.3. 1.4)  originating  from  an  ATC  facility  or  automatically  by 
the  sensor  as  a  result  of  certain  conditions. 

The  ATCRBS  ID  Request  and  the  ATCRBS  ID  Code  Message  will  be 
used  as  a  means  to  maintain  the  compatibility,  for 
DABS-equipped  aircraft,  between  DABS  and  ATCRBS 
identification  codes  in  the  ATC  facilities  by  permitting  the 


association  betwen  the  DABS  Address  and  the  Mode  3/A  Code 
setting  of  the  DABS  transponder  on  a  particular  aircraft. 
During  the  DABS  transition  period,  in  many  instances  a 
DABS-equipped  aircraft  will  be  traversing  the  coverage  of 
both  DABS  and  ATCRBS  sensors  (for  example,  ATCRBS  coverage  of 
a  controlled,  DABS-equipped  aircraft  in  a  DABS/ARTS  facility 
may  result  from  a  nearby  ATCRBS  sensor  connected  to  an 
adjacent  non-DABS  En  Route  ATC  facility). 

If  an  adjacent  non-DABS  facility  is  scheduled  to  receive  a 
handoff  of  the  aircraft  from  a  DABS  facility,  internally 
stored  flight  plans  in  the  ATC  faclity  receiving  the  handoff 
will  contain  the  Assigned  Mode  3/A  code  which  will  be  used  to 
maintain  the  proper  identification  of  the  inbound 
DABS-equipped  aircraft.  Proper  Mode  3/A  identification  is, 
of  course,  required  both  for  the  controller  and  for  automatic 
computer  routines.  For  these  reasons,  the  proper  setting  of 
the  Mode  3/A  code  of  a  DABS-equipped  aircraft  should  be 
maintained  at  the  value  assigned  by  ATC  though  the  track  may 
be  still  controlled  by  an  ATC  facility  connected  to  a  DABS 
sensor . 

Additionally,  a  DABS-equipped  aircraft  in  En  Route  airspace 
may  be  in  the  coverage  of  both  DABS  and  ATCRBS  sensors.  In 
order  to  maintain  proper  identification  of  the  aircraft,  the 
En  Route  ATC  facility  must  maintain  the  correspondence 
between  the  DABS  Address  contained  in  the  DABS  beacon  report 
from  DABS  and  the  Mode  3/A  code  received  in  the  surveillance 
report  from  the  ATCRBS  sensor  (refer  to  Figure  2-6). 

2.8.2  Aircraft  Identification  Information 

An  ATC  facility  may  obtain  the  variable  flight  identification 
(e.g.,  TWA462)  from  an  appropriately  equipped  DABS  aircraft 
by  issuing  a  Request  for  Downlink  Data  (see  Section  3. 3. 1.3) 
to  the  DABS  sensor.  The  DABS  transponder  will  supply  the 
variable  flight  identification  in  a  following  Tactical 
Downlink  Message  (see  Section  3. 3.4.1). 

Use  of  the  variable  flight  identification  (if  any)  is 
important  since  it  will  enable  the  ATC  facility  to  associate 
the  DABS  Address  for  that  aircraft  directly  with  the  flight 
identification.  Thus,  if  a  flight  plan  is  filed  with  the 
aircraft's  flight  identification,  but  with  no  DABS  Address, 
an  inmediate  association  between  the  proper  flight  plan  and 
the  DABS  Address  in  the  surveillance  messages  may  be  made. 
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FIGURE  2-6 

DABS  ADDRESS  AND  ATCRBS  CODE  CORRESPONDENCE  USING 
SURVEILLANCE-RELATED  COMMUNICATIONS 


This  will  permit  automatic  track  initiation  and  track 
identification  to  occur  though  no  DABS  address  information  ia 
available  in  the  stored  flight  plan.  The  procedure  could 
simplify  the  filing  and  handling  of  flight  plans  for 
DABS-equipped  aircraft  using  variable  flight  numbers.  An 
example  is  the  case  of  commercial  airliners  where  various 
aircraft  (therefore  different  DABS  Addresses)  may  fly  the 
same  scheduled  route ,  using  the  same  flight  identification  on 
different  days. 

If  the  DABS  Address  is  contained  in  the  flight  plan,  the  use 
of  the  DABS-provided  flight  identification  can  serve  a^ 
verification  of  DABS  Address/flight  identification 
association. 

2.8.3  Track  Alert  Message 

The  Track  Alert  Message  generated  by  the  sensor  will  inform 
the  ATC  facility  regarding  a  highly  specific,  low  probability 
error  condition.  This  condition  is  the  detection  by  the 
sensor  of  two  distinct  tracks  containing  the  same  DABS 
Address.  Since  DABS  transponders  will  be  designed  to  encode 
a  unique  hard-wired  address,  this  duplicate  address  situation 
will  only  arise  if  (1)  either  a  transponder  or  the  sensor 
makes  a  systematic  error  that  converts  the  true  address  into 
a  different  address  in  a  consistent  manner,  and  (2)  another 
aircraft  happens  to  be  on  the  local  sensor  roll  call  (or  in 
some  cases  on  an  adjacent,  connected  sensor's  roll  call)  at 
the  same  time  and  its  DABS  Address  matches  the  erroneous  one. 

When  a  DABS  sensor  detects  a  duplicate  address  condition,  the 
respective  DABS  Address  will  be  deleted  from  the 
interrogation  roll  call  so  that  surveillance  interrogations 
on  both  aircraft  are  generated  in  the  All-Call  mode  only.  As 
a  result,  the  DABS  uplink  and  downlink  is  no  longer  available 
for  the  aircraft  as  long  as  the  problem  persists  and  only 
DABS  beacon  reports  based  on  All-Call  replies  will  be 
disseminated.  In  addition,  the  Track  Alert  Message  will  be 
transmitted  to  each  ATC  facility  connected  to  the  sensor  via 
the  ground  communications  link.  The  message  will  contain  the 
DABS  Address  in  question  and  the  position  (range  and  azimuth 
only)  of  each  of  the  two  targets. 

A  similar  error  condition  may  arise  in  which  two  aircraft 
simultaneously  report  the  same  DABS  Address  to  two  different 
DABS  sensors,  which  in  turn  report  to  the  same  ATC  Facility. 


If  there  ie  non-overlapping  coverage  of  these  two  aircraft  or 
if  the  sensors  are  not  connected,  each  sensor  will  be  aware 
of  only  one  aircraft,  and  the  DABS  cannot  alert  the  ATC 
Facility  to  the  situation. 
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3 .  AIR-GROUND  COMMUNICATIONS 


3 . 1  Intr oduc  t ion 


DABS  not  only  provides  an  improved  surveillance  system,  but  also 
provides  an  integral  data  link.  In  the  performance  of  its 
surveillance  responsibilities  DABS  can  accomplish  two-way 
message  delivery,  from  the  ground  to  an  aircraft  and  from  an 
aircraft  to  the  ground.  This  digital  data  link  will  allow  the 
automation  of  ATC  services  to  evolve. 

In  order  to  discuss  the  DABS  data  link,  it  is  necessary  to 
define  the  types  of  messages  handled  by  DABS.  Both  uplink 
(ground-to-aircraft)  and  downlink  (a ire raft -to-ground)  messages 
consist  of  two  types,  "standard"  and  "extended  length". 

Standard  messages  are  fixed  in  length  and  each  message  requires 
a  reply.  (Every  downlink  reply  is  an  acknowledgement  of  message 
acceptance  by  the  transponder.)  A  standard  uplink  message  is 
sometimes  referred  to  as  a  "Comm- A"  transaction  while  a  standard 
downlink  message  is  called  a  "Comm-B"  transaction.  Extended 
length  messages  (ELM's)  are  used  for  applications  which  require 
the  transfer  of  a  large  amount  of  text.  Basically  an  ELM 
consists  of  a  variable  number  of  fixed  length  messages  linked 
together  and  only  requiring  one  reply  for  the  entire  message. 

The  uplink  ELM  is  a  collection  of  "Comm-C"  interrogations  while 
the  downlink  ELM  makes  use  of  the  "Comm-D"  replies. 

The  remainder  of  this  chapter  will  describe  the  DABS  data  link 
in  terms  of:  (1)  its  characteristics,  (2)  messages,  (3)  the 
necessary  interaction  with  the  ATC  facility,  and  (4)  example 
applications.  Messages  associated  with  ATARS  will  be  discussed 
in  the  ATARS  section  of  this  document. 

3.2  Characteristics  of  Air-Ground  Data  Link 


The  DABS  sensor  provides  all  the  necessary  data  link  management 
to  ensure  accurate  delivery  of  a  properly  formatted  message  to 
an  aircraft  within  its  area  of  responsibility.  In  general,  the 
ATC  facility  is  only  required  to  formulate  message  inputs  to  the 
data  link,  and  to  route  outputs  from  the  data  link  to  the 
appropriate  device. 

Figure  3-1  depicts  a  simplified  data  link  system  concept.  As 
shown,  the  DABS  site  has  a  surveillance  ground  link  to  one  or 
more  ATC  facilities  over  which  target  reports  are  sent.  In 
addition  a  full  duplex  communication  ground  link  exist  between 
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FIGURE  3-1 

SIMPLIFIED  DATA  LINK  SYSTEM 


the  DABS  site  and  the  ATC  Facility.  This  link  is  connected  to 
the  ATC  facility  automation  computers  to  provide  ATC  message 
services  such  as  Altitude  Clearance  Confirmation  and  Minimum 
Safe  Altitude  Warning  (MSAW)  advisories. 

Communications  among  the  ATC  facility,  the  DABS  sensor,  and  the 
transponder  is  a  process  that  is  actually  comprised  of  two  data 
links.  The  "ground  link"  is  a  two-way  data  link  between  the 
DABS  sensor  and  an  ATC  facility.  The  "air  link"  is  the  data 
link  between  the  DABS  sensor  and  the  transponder  consisting  of 
an  "uplink"  and  a  "downlink".  In  its  basic  form,  the 
communication  process  between  the  ATC  facility  and  the  pilot 
consists  of: 

1.  A  message  transmitted  from  the  ATC  facility  to  a  DABS 
sensor, 

2.  Processing  that  message  by  the  DABS  computers  to  set  up 
a  ground-to-air  message 

3.  Transmission  of  the  uplink  message,  and 

4.  Processing  of  the  message  in  the  aircraft  for  display 
to  the  pilot. 

Data  link  communication  from  the  pilot  to  the  ATC  facility 
begins  with  a  request  to  use  the  "air link" .  This  step  is 
necessary  since  the  air  link  is  under  control  of  the  sensor,  not 
the  transponder.  The  transaction  begins  with  the  pilot 
arranging  his  message  on  an  input  device  and  pushing  a  "send" 
button.  This  causes  a  flag  to  be  set  in  every  subsequent 
surveillance/standard  message  reply.  When  the  sensor  reads  the 
reply,  it  knows  that  a  message  is  waiting  and  schedules  an 
interrogation  calling  for  a  standard  downlink  reply  containing 
the  message  data.  After  the  message  has  been  correctly  received 
the  sensor  sends  up  a  signal  in  a  subsequent  interrogation  that 
resets  the  flag  and  indicates  to  the  pilot  that  the  transaction 
has  been  completed. 

Each  of  the  data  link  message  transmissions  requires  the  use  of 
a  protocol  that  protects  the  message  against  loss  and  notifies 
the  originator  when  the  message  has  been  received  or  if  it 
cannot  be  delivered.  Further  brief  discussions  of  both  message 
formats  and  protocols  are  contained  in  other  sections  of  this 
document;  however,  detailed  information  on  message  formats  and 
protocols  can  be  found  in  References  1  and  4. 


The  remainder  of  this  section  will  include  some  general 
characteristics  of  message  handling,  as  well  as  a  discussion  of 
the  capabilities  and  performance  characteristics  of  the  data 
link. 

3.2.1  DABS  Message  Routing* 

3. 2. 1.1  Uplink  Message  Routing 

For  the  purpose  of  delivering  uplink  messages,  DABS  sensors 
normally  act  independently  (even  though  they  may  be  netted  and 
two  or  more  sensors  may  be  interrogating  the  same  aircraft). 
Thus,  if  a  sensor  receives  a  message  for  an  aircraft,  it  will 
attempt  delivery  without  knowledge  of  whether  or  not  other 
sensors  are  handling  the  same  message.  In  the  case  of  a  sensor 
receiving  an  ELM  uplink,  transmission  will  be  attempted  only  if 
the  sensor  is  designated  Primary  for  the  particular  aircraft. 

3.2.1 .2  Downlink  Message  Routing 

For  pilot-originated  messages  (downlinks),  processing  by 
multiple  sensors  cannot  be  permitted  without  risking  the  loss  of 
messages  under  some  circumstances.  DABS  (see  Reference  2, 
Section  3.4.8)  solves  the  problem  with  the  "Primary /Secondary 
sensor"  assignment  scheme,  which  allows  only  the  Primary  sensor 
to  extract  the  downlink  message. 

For  controlled  aircraft  the  Primary/Secondary  designation  of  a 
sensor  will  depend  on  an  explicit  assignment  contained  in  a 
message  from  the  ATC  facility  (Section  5.2.6).  For  an 
uncontrolled  aircraft,  the  Primary  sensor  is  the  "best"  sensor 
defined  by  the  coverage  map.  For  uncontrolled  aircraft  in 
"transition"  zones  (irre^-larly  shaped  strips  along  the 
Primary /Secondary  boundaries  between  sensors),  DABS  network 
management  allows  a  "Dual  Primary"  designation  on  the  coverage 
map.  For  "netted"  sensors  (sensors  connected  by  ground  lines), 


In  conjunction  with  message  handling,  it  is  useful  to  consider 
ATARS  as  functionally  distinct  from  DABS  sensor  processing. 

Thus,  ATARS  acts  as  an  originator  and  recipient  of  messages,  (1) 
to  aircraft,  using  collocated  and/or  adjacent  DABS  sensors,  (2) 
to  ATC  facilities,  and  (3)  to  adjacent  ATARS.  In  this  sense, 
ATARS  is  treated  as  another  external  user  of  DABS  communications 
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actual  Dual  Primary  is  prevented  by  coordination  between  the 
sensors.  In  the  "non-netted"  case,  all  Primary  sensors  will 
attempt  to  extract  downlink  messages.  However,  loss  of  messages 
is  prevented  by  special  DABS  "multi-site  protocol"  (see 
References  2  and  4). 

The  DABS  sensor  receiving  a  downlink  message  has  responsibility 
for  routing  the  resulting  output  on  the  ground  links.  When  the 
downlink  is  a  specific  response  to  a  particular  ATC  facility 
input,  the  message  will  be  directed  only  to  that  user.  When  the 
downlink  is  pilot-originated,  the  DABS  sensor  will  disseminate 
the  output,  following  the  same  site  adapted  dissemination  map 
(Section  2.6)  that  is  used  for  surveillance  data  outputs. 

3.2.2  Data  Delays 

In  DABS  data  link  communications,  time  delays  in  the 
transmission  and  receipt  of  data  naturally  occur.  The  total 
time  that  may  elapse  between  the  initiation  of  a  message  at  an 
ATC  facility  and  its  receipt  by  the  aircraft  is  a  function  of 
many  elements.  For  an  ATC  generated  uplink  message  the  delays 
inc lude : 

1.  Processing  within  the  ATC  facility's  processor, 

2.  Processing  and  waiting  time  at  the  ATC  ground  link 
transmission  interface, 

3.  Ground  link  transit  time  including  possible  delays  for 
"reject"  replies  and  subsequent  retransmissions  in  cases  of 
link  difficulties, 

4.  Processing  time  at  the  DABS  ground  link  receive 
interface, 

3.  DABS  software  processing  delays, 

6.  Waiting  time  for  antenna  to  reach  aircraft  azimuth,  and 

7.  Possible  delays  for  retransmissions  in  cases  of  airlink 
difficult ies. 


For  normal  operations  of  the  uplink,  messages  will  be  delayed  no 
more  than  1/16  of  a  scan  (0.25  seconds  for  a  4-second  rotating 
antenna)  from  the  time  of  receipt  by  the  sensor  until  they  are 


processed  and  available  for  delivery  to  the  aircraft.  The 
average  delay  time  for  item  6  in  the  preceding  list  is  1/2  a 
scan,  while  the  delay  for  item  7  could  be  substantial  if  a  link 
fade  extends  over  an  entire  beam  dwell  period. 

For  downlink  messages,  the  delays  occur  in  reverse  order  but  are 
comparable.  A  delay  of  no  more  than  3/32  of  a  scan  period 
(0.375  seconds  for  4-second  rotating  antenna)  will  occur  from 
the  time  the  target  was  in  the  beam  until  the  (data  is  processed 
by  the  sensor  and  is  available  for  transmission  to  the  external 
user.  In  some  cases  there  will  be  an  additional  1-scan  delay 
between  transmission  of  a  pilot's  "send"  request  and  the 
subsequent  extraction  of  his  message.  Messages  handled  under 
the  Data  Relay  Mode  (Reference  3)  undergo  additional  delays  for 
processing  by  the  relaying  sensor  and  for  transmission  on  the 
sensor-to-sensor  link. 

A  simple  priority  system  for  uplink  message  transmissions  has 
some  bearing  on  data  delays.  Standard  transmissions  (Comm'A's) 
and  ELM's  carry  an  explicit  1-bit  tag  (determined  by  message 
originator)  representing  "high"  or  "standard"  priority.  All 
"high"  priority  standard  transmissions  are  handled  first 
followed  by  the  remaining  Comm-A's,  then  any  ELM's,  which  are 
assigned  to  a  class  below  "standard".  It  should  be  noted  that 
ATARS  "high"  priority  messages  may  be  given  preference  over 
other  "high"  priority  messages  by  the  setting  of  a  global 
"precedence"  parameter  (Reference  2).  Also  all  messages  within 
a  priority  class  are  handled  on  a  first-in-first-out  basis. 

These  priority  levels  do  not  affect  the  handling  of  a  message  on 
the  ground  link  or  in  most  of  the  DABS  processing.  They  do 
affect  the  order  of  message  delivery  on  the  uplink  but  the 
effect  will  only  be  noticed  in  times  of  heavy  message  queuing 
when  a  low  priority  assignment  would  increase  the  probability 
that  the  message  transmission  would  be  delaved  to  the  next  scan. 

Related  to  the  subject  of  data  delays  is  an  uplink  message 
parameter  "expiration  time"  which  is  determined  by  the  user 
(standard  default  value  supplied  by  DABS).  This  parameter 
defines  the  number  of  scans  during  which  the  DABS  sensor  will 
continue  to  attempt  delivery  of  the  message,  and  in  turn, 
defines  an  upper  bound  to  the  range  of  possible  data  delays. 

3.2.3  Capabilities  and  Performance  Characteristics 

The  DABS  sensor  is  designed  to  provide  a  high  capacity, 
reliable,  two-way  digital  data  link' for  all  DABS-equipped 
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aircraft.  The  sensor  has  a  capacity  that  exceeds  all  projected 
data  link  applications.  This  includes  ATARS,  ATC  messages, 
weather  services,  terminal  information  services,  downlink  of 
airborne  measurements,  etc. 

To  help  insure  a  reliable  data  link,,  all  "airlink"  messages 
include  a  24  bit  Address/Parity  field  (Reference  3)  which  allows 
for  detection  of  most  uplink  transmission  errors,  and  detection 
and  correction  of  most  downlink  transmission  errors  which  are 
caused  by  ATCRBS  interference.  Another  feature  which  adds  to 
data  link  reliability  is  the  ability  of  the  sensor  to 
reinterrogate  an  aircraft  within  a  beam  dwell  when  an  expected 
reply  is  not  received. 

3.2.4  Data  Link  Protocols 


3. 2. 4.1  "Airlink"  Channel  Protocol 


For  proper  operation  of  the  "airlink",  adherence  to  basic 
protocol  principles  is  necessary.  First,  for  a  particular  DABS 
target,  only  one  sensor  (the  Primary  sensor)  at  a  time  is 
allowed  to  read  out  pilot-originated  messages,  deliver  altitude 
echo  (ALEC),  deliver  traffic  advisories,  provide  synchronized 
interrogations  (optional  DABS  mode),  and  perform  EU1 
transactions.  However,  additional  sensors  may  perform 
surveillance,  deliver  uplink  messages  (Comm-A's)  and  read  out 
ground-requested  downlink  messages  (Comm-B's).  Next,  the 
"airlink"  always  operates  under  ground  (sensor)  control,  meaning 
that  the  transponder  must  notify  the  sensor  that  a  downlink 
message  is  awaiting  delivery  ("B"  bit  set)  and  that  the  sensor 
must  then  schedule  an  interrogation  for  extraction  of  the 
message.  Once  extracted,  the  sensor  positively  resets  the 
transponder's  downlink  status  ("Cancel  B").  Another  basic 
protocol  principle  is  that  every  downlink  reply  is  a  "technical 
acknowledgment"  of  an  uplink  interrogation,  implying  that  the 
uplink  message  was  received  and  properly  decoded. 

The  procedures  for  uplink  message  delivery  begin  with  the 
tagging  of  the  messages  with  the  sender's  ID  code  and  then  the 
placement  of  the  messages  in  a  single  buffer  in  the  order 
received.  (This  buffer  is  read  at  least  16  times  during  an 
antenna  scan  period.)  DABS  data  link  processing  then  searches 
the  surveillance  file  for  the  aircraft  addressed  in  the  message 
and : 
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If  the  aircraft  is  not  on  file,  the  message  is  deleted 
and  a  Message  Rejection  Notice  (Section  3. 3. 3.1)  is 
sent  to  the  sender  indicating  "rejection". 

2.  If  the  aircraft  is  on  file,  but  not  being  tracked  with 
roll  call  data  (sensor  fade  exists),  the  message  is 
accepted  but  a  Message  Delay  Notice  is  sent  indicating 
"delay". 

3.  If  the  message  is  an  Uplink  ELM  addressed  to  an 
aircraft  for  which  the  sensor  is  not  assigned  Primary, 
a  Message  Rejection  Notice  is  sent  indicating 
"rejection"  for  the  reason  specified. 

4.  If  the  message  is  an  uplink  ELM  and  the  aircraft 
addressed  lacks  ELM  capability,  a  Message  Rejection 
Notice  is  sent  indicating  "rejection"  for  the  reason 
specified. 

5.  If  the  message  is  being  "relayed"  to  another  DABS 
sensor  for  delivery,  a  Message  Delay  Notice  is  sent 
indicating  "delay"  for  the  reason  specified. 

6.  Otherwise,  the  message  is  accepted. 

Each  accepted  message  is  then  placed  in  a  file  for  the 
particular  aircraft  by  message  type  (Standard  or  ELM)  and 
priority  level.  Within  a  type  and  priority  level  the  messages 
are  processed  in  the  order  received.  No  message  will  be 
delivered  until  those  preceding  it  in  the  list  have  been 
completed.  Delivery  of  all  messages  in  the  list  is  attempted 
the  next  time  the  aircraft  is  in  the  sensor  antenna  beam. 
However,  if  any  message  ‘ r.  not  successfully  delivered  during  the 
beam  dwell  it  is  saved  for  the  next  scan  unless  expiration 
occurs. 

In  the  case  of  message  expiration,  the  message  is  deleted  and  a 
Message  Delivery  Notice  (Section  3. 3. 3. 2)  is  sent  to  sender 
indicating  "expired".  For  each  tactical  uplink  and  complete  ELM 
delivered,  a  Message  Delivery  Notice  is  sent  to  the  sender 
indicating  "delivered". 

3. 2. 4. 2  Ground  Link  Protocol 


Messages  between  DABS  sensors  and  ATC  facilities  conform  to  the 
protocol  and  formats  of  the  Common  International  Civil  Aviation 
Organization  (ICAO)  Data  Interchange  Network  (CIDIN).  The 
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purpose  of  this  protocol  is  to  help  provide  confidence  and 
reliability  in  the  ground  link  operation.  None  of  the  protocol 
operations,  other  than  parity  encoding  and  error  detection, 
involves  the  link  data  field  contents  (message  data). 

In  order  to  use  the  DABS  data  link  the  ATC  facility  will  need  to 
provide  a  proper  interface  (hardware/software)  which  provides 
translation  between  the  CIDIN  protocol  and  message  formats  and 
the  protocol  and  formats  used  on  the  corresponding  ATC 
computers.  Under  normal  operating  conditions  the  interface 
(hardware/software)  will  be  transparent  to  the  user.  A 
discussion  of  both  the  interface  with  an  ARTS  IIIA  facility  and 
an  En  Route  facility  is  presented  in  Section  6,  and  in  Reference 
7. 

3.2.5  Considerations  for  Multi-Sensor  Configurations 

A  multi-sensor  configuration  allows  the  ATC  facility  software  to 
designate  which  sensor  is  "Primary"  for  controlled  aircraft  by 
issuance  of  an  "Aircraft  Control  State"  message.  This  will 
insure  a  data  link  between  the  ATC  facility  and  the  aircraft  in 
control  areas  not  normally  serviced  by  the  attached  sensor 
(e.g.,  early  interfacility  handoff). 

A  sensor  failure  will  be  transparent  to  the  controller  in  terms 
of  interaction  with  the  data  link.  (This  assumes  all  aircraft 
of  interest  are  provided  surveillance  and  data  link  services  by 
reconfiguration  of  coverage  areas  of  remaining  operational 
sensors).  With  a  sensor  failed,  the  multi link  feature  may  be 
lost,  but  the  actions  by  controller/ATC  software  will  be 
unchanged . 

3.3  Data  Link  Messages 

The  purpose  of  this  section  is  to  operationally  describe  the 
various  messages  and  message  types  to  effect  the  use  of  the  DABS 
data  link.  For  specific  message  type  codes  and  formats,  see 
References  1,  2,  and  4. 

3.3.1  ATC-to -DABS  Uplink  Messages 

Among  the  messages  that  are  defined  for  the  link  from  the  ATC 
Facility  to  a  DABS  sensor,  specific  types  are  classified  as 
"uplink  messages"  —  messages  that  are  sent  to  DABS  for  further 
transmission  to  an  aircraft.  The  information  content  as  well  as 
the  DABS  sensor  handling  of  each  type  are  characterized  in  the 
following  paragraphs. 


3. 3. 1.1  Tactical  Uplink 


This  will  be  the  basic  message  for  transmitting  information  from 
an  ATC  facility  or  ATARS  to  the  pilot.  Each  tactical  uplink 
message  transmitted  on  the  ground  link  causes  the  DABS  sensor  to 
dispatch  a  standard  (Comm-A)  uplink  transmission  to  a  particular 
DABS-equipped  aircraft.  The  tactical  uplink  format  includes  a 
DABS  Address  to  identify  the  intended  aircraft,  a  message  number 
to  permit  references  to  the  uplink  message  in  DABS  response 
messages,  expiration  time,  priority,  and  the  message  text  field 
which  contains  the  actual  data  to  be  sent  on  the  uplink.  The 
message  text  field  consists  of  56  bits.  The  contents  of  this 
field  are  not  interpreted  by  the  DABS  sensor  but  are  passed 
intact  as  part  of  the  Comm-A  interrogation. 

The  originating  facility  (ATC  or  ATARS)  will  supply  the  DABS 
aircraft  ID  and  the  message  text.  Expiration  time  and  priority 
are  optional  and  will  assume  nominal  values  unless  set  by  the 
originator.  For  transmisson  of  urgent  messages,  maximum  speed 
and  reliability  are  obtained  by  sending  the  message  via  all 
available  DABS  sensors,  e.g.  "multilink"  handling. 

3. 3. 1.2  ELM  Uplink 

This  message  type  will  be  used  for  longer  messages  from  the  ATC 
facility  to  the  pilot.  The  protocol  associated  with  EIM's  is 
intended  to  make  more  efficient  use  of  the  air-ground  channel 
than  is  possible  with  standard  (Comm-A  and  Comm-B) 
transmissions,  which  require  two-way  transmissions  for  each 
segment.  The  EIX  only  requires  one  reply  for  the  complete 
message.  The  ELM  uplink  format  includes  the  DABS  address, 
message  number,  priority,  and  expiration  time  defined  as  for  the 
tactical  uplink.  The  remainder  of  the  message  is  a  "length" 
parameter,  which  is  a  segment  counter  with  a  maximum  of  16  and  a 
minimum  of  2  segments,  and  an  ELM  text  field. 

The  EU1  text  is  variable  in  length  in  multiples  of  80  bits  with 
a  maximum  of  1280  bits.  If  longer  messages  were  to  be  sent, 
they  would  have  to  be  subdivided  and  would  be  treated  by  DABS  as 
independent  ELM's.  The  ELM  text  field  is  not  interpreted  by  the 
DABS  sensor  but  is  used  intact  in  a  sequence  of  Comm-C  uplink 
transmissions.  Coding  for  this  field  must  satisfy  the 
requirements  of  an  ELM  output  device. 

Only  the  DABS  sensor  designated  as  Primary  for  a  particular 
aircraft  will  transmit  an  uplink  ELM,  therefore  the  ATC  facility 
must  route  the  message  to  the  Primary  sensor. 
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3.3.1 .3  Request  for  Downlink  Data 


This  message  will  be  used  to  obtain  data  from  a  device  on  a 
DABS-equipped  aircraft  using  an  air-to-ground  standard  (Comm-B) 
transmission.  The  message  format  contains  the  DABS  address, 
message  number,  expiration  time,  priority,  and  a  4-bit  field 
indicating  the  requested  data. 

3. 3. 1.4  ATCRBS  ID  Request 

Since  DABS  transponders  incorporate  an  ATCRBS  capability, 
provision  is  included  to  read  out  the  Mode  3/A  code  via  the  DABS 
link.  The  ID  request  is  similar  to  a  request  for  downlink  data, 
except  the  Comm-B  downlink  is  not  required.  Instead,  the 
standard  reply  transmission  format  (short  or  long)  may  include 
the  mode  3/A  code  in  place  of  altitude.  The  ATCRBS  ID  Request 
format  comprises  simply  a  DABS  address  and  message  number.  A 
DABS  sensor,  without  waiting  for  a  request,  will  routinely  ask 
for  a  Mode  3/A  reply  and  disseminate  a  response  whenever  a  DABS 
equipped  aircraft  is  acquired,  reacquired,  and  whenever  the 
pilot  changes  his  Mode  3/A  code. 

ATC  surveillance  processing  software  will  automatically  generate 
this  message  whenever  a  new  DABS  aircraft  is  reported  and  an 
ATCRBS  ID  message  is  not  received  promptly. 

3. 3. 1.5  Message  Cancellation  Request 

For  various  reasons,  at  times,  it  may  be  desirable  to  cancel 
either  a  tactical  or  ELM  uplink  message.  (Other  types  of  uplink 
messages  do  not  result  in  display  of  data  to  the  pilot, 
therefore  no  cancellation  is  necessary.)  This  is  the  function 
of  the  message  cancellation  request.  The  format  contains  the 
DABS  address,  message  number,  reference  message  number  and  type 
that  identify  the  message  to  be  cancelled.  Following  the 
attempt  to  delete,  there  is  no  further  specific  response  from 
the  sensor  to  the  message  originator  as  to  the  status  of  the 
cancellation  request.  The  user  has  no  guarantee  of  stopping 
message  delivery. 

3. 3. 1.6  Data  Link  Capability  Request 

This  message  is  a  request  for  the  "data  link  capability  field" 
which  identifies  the  capability  of  the  onboard  equipment  to 
generate  and/or  receive  specific  types  of  communications.  The 
message  format  contains  only  the  DABS  address.  This  capability 
information  is  needed  by  the  ATC  facility  and  ATARS  before  they 
attempt  sending  uplink  messages  to  an  aircraft. 
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Upon  receipt  of  a  Data  Link  Capability  Request  the  sensor  will 
transmit  to  the  user  via  a  Data  Link  Capability  Message  (Section 
3. 3. 4. 3)  the  contents  of  the  capability  field  in  the  aircraft's 
surveillance  file. 

ATC  software  will  automatically  generate  this  message  whenever  a 
new  DABS  aircraft  is  reported  and  a  Data  Link  Capability  Message 
is  not  received  within  a  predetermined  time. 

3.3.2  ATC-to-DABS  Status /Control  Messages 

DABS  status/control  messages  are  used  to  determine  the 
operational  status  of  a  DABS  sensor  and  to  provide  network 
control.  These  messages  are  discussed  in  Section  5  of  this 
document,  but  are  listed  here  for  completeness: 

.  Test  Message 

.  Altimeter  Correction  Message 

.  ATC  Failure /Recovery  Message 

.  Sensor  Failure /Recovery  Message 

.  Aircraft  Control  State  Message  (ATCRBS  and  DABS) 

3.3.3  DABS-to-ATC  Sensor  Response  Messages 

Response  messages  are  generated  by  the  DABS  sensor  as  part  of 
two  distinct  processes  that  take  place  sequentially  following 
the  receipt  of  an  uplink  message.  The  first  process  is 
acceptance  testing,  which  determines  the  deliverability  of  each 
uplink  message  of  any  type.  The  second  process  is  that  of 
technical  acknowledgement,  and  it  is  carried  out  after  uplink 
transmission  of  tactical  or  ELM  message  types,  provided  they 
have  passed  the  acceptance  test.  There  are  two  types  of 
response  messages,  and  they  correspond  exactly  to  the  two 
processes. 

3. 3. 3.1  Message  Rejection/Delay  Notice 

Acceptance  testing  of  each  uplink  message  consists  of  a  search 
of  the  DABS  sensor  surveillance  file  for  the  aircraft  addressed 
and  a  test  on  the  track  state  of  that  aircraft.  For  an  uplink 
ELM,  acceptance  also  depends  on  the  sensor  being  Primary  for  the 
aircraft  addressed.  There  are  five  possible  outcomes  to  the 
acceptance  testing: 

1.  Rejection,  because  target  is  not  on  file 

2.  Rejection,  because  sensor  is  not  Primary  (uplink  Em 
only) 
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3.  Rejection,  target  lacks  ELM  capability 

4.  Delay,  because  target  is  not  in  roll  call  mode 

5.  Delay,  because  of  data  relay  (with  or  without  local 
delivery),  and 

6.  Acceptance  (no  Notice  sent) 

which  are  explained  in  Reference  1.  The  message  contains  three 
data  fields,  the  DABS  address,  the  reference  message  number,  and 
a  "qualifier"  representing  the  test  outcome. 

Upon  receipt  of  a  Message  Rejection  Notice  (for  cases  1  and  2 
above)  the  ATC  software  will  provide  for  automatic  re-issuing  of 
the  message  to  another  connected  DABS  sensor.  For  a  Message 
Delay  Notice  no  action  is  required,  except  possibly  for  a 
high-priority  message  which  would  require  re-initiation  of  the 
message  using  another  sensor  if  available. 

3. 3. 3. 2  Message  Delivery  Notice 

When  a  tactical  uplink  message  is  delivered  by  means  of  a  Comn-A 
transmission,  the  received  transponder  reply  constitutes  a 
technical  acknowledgment  of  the  receipt  of  that  message.  For 
segments  of  ELM  uplinks,  the  procedure  is  more  elaborate  and 
results  in  technical  acknowledgements  specific  to  each  segment. 
Whenever  a  tactical  uplink  message  or  all  segments  of  an  ELM 
uplink  message  have  been  acknowledged,  the  DABS  sensor  generates 
a  Message  Delivery  Notice  for  the  originator  indicating 
successful  delivery.  If  any  segment  of  an  ELM  is  not 
acknowledged  on  the  downlink,  the  sensor  will  continue  to 
attempt  delivery  until  the  expiration  time  of  the  message  is 
reached.  If  any  part  of  the  message  remains  undelivered  at 
expiration  time,  a  delivery  notice  is  generated  indicating 
failure.  The  Message  Delivery  Notice  contains  three  data 
fields,  the  DABS  Address,  referenced  message  number,  and 
delivery  indicator. 

ATC  software  will  provide  for  indication  of  a  successful  message 
delivery  to  the  originator.  A  notice  indicating  failure  of 
delivery  will  also  be  displayed,  allowing  re-initiation  via 
another  sensor  by  action  of  originator. 

3.3.4  DABS-to-ATC  Downlink  Messages 

Downlink  messages  to  ATC  are  generated  by  the  DABS  sensor  as  a 
result  of  information  received  via  the  DABS  downlink.  Such 
information  may  originate  with  the  pilot  or  it  may  result 
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directly  from  a  previous  uplink  message.  There  are  five 
specific  types  of  downlink  messages,  each  of  which  is 
characterized  in  the  following  sections. 

3. 3. 4.1  Tactical  Downlink  and  Utility  Messages 

A  Tactical  Downlink  Message  is  generated  whenever  a  DABS  sensor 
receives  a  Comn-B  reply.  A  tactical  downlink  message  is 
comprised  of  a  single  segment  of  data;  consequently,  if  an 
airborne  device  is  used  that  generates  more  than  one  Comm-B 
segment,  separate  independent  messages  will  result.  Hie 
tactical  message  generated  will  be  routed  to  either:  (1)  all 
ATC  Facilities  receiving  DABS  surveillance  data  on  the  aircraft 
if  the  Comn-B  was  extracted  at  the  request  of  the  pilot,  or  (2) 
the  specific  ATC  Facility  or  ATARS  that  requested  the 
information. 

The  downlink  message  format  contains  two  fields,  the  DABS 
address  and  the  56-bit  message  text  (MB)  which  is  not 
interpreted  by  the  DABS  sensor.  Any  desired  control  data  must 
be  coded  into  the  MB  field. 

The  ATC  processing  software  must  interpret  the  MB  data  and 
extract  the  definition  subfield.  If  it  matches  the  address  code 
in  a  pending  "Request  for  Downlink  Data"  for  that  aircraft  then 
the  proper  association  has  been  made,  and  (1)  the  message  will 
be  routed  to  the  appropriate  device,  (2)  the  message  contents 
displayed  and,  (3)  the  pending  request  deleted  from  the  software 
files.  If  there  is  no  definition  subfield  code  match  or  no 
pending  request,  the  downlink  message  is  assumed  to  be 
pilot-originated  and  routed  accordingly. 

The  Utility  Message  is  routed  like  a  pilot-originated  tactical 
message.  The  message  contains  the  DABS  address  and  the  6-bit  UM 
data  field  (References  1  and  4)  not  interpreted  by  the  DABS 
sensor,  which  is  contained  in  both  surveillance  and  standard 
(Comm-B)  replies.  The  DABS  sensor  generates  a  Utility  Message 
only  when  the  UM  field  contains  information  (Non-zero)  which  has 
not  been  requested  by  the  sensor. 

3. 3. 4. 2  ELM  Downlink  Messages 

An  ELM  downlink  message  can  be  pilot  originated  or  requested  by 
the  ground.  Only  one  message  at  a  time  can  be  in  progress  and 
only  the  DABS  Primary  sensor  for  that  aircraft  will  attempt  to 
extract  it.  The  message  corresponds  to  a  sequence  of  Comm-D 
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replies,  each  containing  one  segment  of  data.  The  message 
format  consists  of  three  data  fields;  the  DABS  address  of  the 
sending  aircraft,  the  "length"  parameter  specifying  the  number 
of  segments  in  the  message,  and  the  ELM  text  (not  interpreted  by 
the  DABS  sensor).  The  ELM  text  is  variable  in  length  in 
multiples  of  80  bits  to  a  maximum  of  1280.  The  text  field  is 
assembled  by  copying  the  MD  fields  of  the  Coram-D  replies  in  the 
proper  sequence.  The  E1>1  message  will  not  be  sent  to  the  ATC 
facility  until  all  segments  of  the  downlink  have  been  received 
by  the  DABS  sensor.  The  ATC  processing  software  will  have  to 
perform  routing  to  appropriate  devices  and  in  addition,  check 
for  completion  of  the  message. 

3. 3.4. 3  Data  Link  Capability  Message 

This  message  is  used  to  report  the  data  link  capability  field. 

It  is  generated  automatically  by  DABS  either  (1)  when  a  new  DABS 
aircraft  is  acquired,  or  (2)  the  aircraft  reports  a  change  in 
its  data  link  capability,  or  (3)  when  requested  by  an  ATC 
facility  or  ATARS  by  means  of  a  Data  Link  Capability  Request 
Message  (Section  3. 3. 1.6).  In  the  latter  case,  the  message  is 
transmitted  to  only  the  requesting  facility;  in  the  former  case, 
to  all  facilities  receiving  surveillance  reports.  The  message 
format  simply  contains  the  DABS  address  and  the  capability  field 
(Reference  1). 

A  data  link  capability  message  will  require  ATC  software 
processing.  The  data  contained  in  the  message  will  indicate  to 
the  ATC  software  the  capability  of  the  onboard  equipment  to 
generate  and/or  receive  specific  types  of  communications  for  a 
particular  DABS  aircraft.  This  information  must  be  stored  and 
made  available  to  the  appropriate  data  link  function  as  part  of 
the  aircraft  status  or  data  link  display  maintained  in  the  ATC 
sof tware . 

3. 3.4.4  ATCRBS  ID  Code  Message 

This  message  is  generated  whenever  a  DABS  sensor  receives  a 
reply  from  a  DABS  transponder  containing  a  Mode  3/A  code.  Such 
a  reply  may  occur  for  any  of  several  reasons:  (1)  an  ATCRBS  ID 
code  request  is  received  from  an  ATC  facility,  (2)  the  pilot  has 
changed  his  ID  code  creating  an  "Alert"  status  which  indicates 
his  wish  to  have  his  code  read  out,  (3)  the  pilot  has  dialed  an 
emergency  code  7500,  76xx,  or  77xx,  or  (4)  the  aircraft  has  been 
newly  acquired  or  reacquired  after  a  link  fade  by  the  DABS 
sensor.  In  the  latter  case,  this  message  is  disseminated  only 
if  the  code  show9  a  change.  If  the  reply  results  from  a  code 


request  message  from  a  single  facility,  the  resulting  output 
message  is  transmitted  to  only  that  user.  In  all  other  cases, 
the  ATCRBS  ID  code  message  is  transmitted  to  all  facilities 
receiving  surveillance  reports  on  the  particular  aircraft.  The 
message  format  contains  only  the  DABS  address  and  the  12-bit 
Mode  3 /A  code. 

Receipt  of  an  ATCRBS  ID  Code  Message  requires  the  ATC  software 
processor  to  check  any  pending  ATCRBS  ID  code  request;  if  an 
association  is  made  the  message  is  then  routed  to  the 
appropriate  device  for  display  and  the  request  deleted.  The 
software  processor  will  check  all  messages  of  this  type 
(including  surveillance  replies)  for  emergency  codes  and  if 
found,  route  the  message  for  display  on  all  appropriate 
devices. 

3.3.5  ATARS-to-ATC  Operational  Messages 

The  Controller  Alert  Message  is  discussed  in  the  ATARS  section 
of  this  document  (Section  4)  and  is  only  listed  here  for 
completeness: 

States  of  the  Controller  Alert  Message  (Section  4.3.1) 

.  Conflict  Resolution  Data 
.  Resolution  Notification 
.  Terrain  Avoidance  Alert 
.  Restricted  Airspace  Avoidance  Alert 
.  Obstacle  Avoidance  Alert 

3.3.6  DABS-to-ATC  Performance/Status  Messages 

Continuous  knowledge  of  the  status  of  the  DABS  sensor  is 
important  to  an  ATC  Facility  for  two  reasons.  First,  it  is 
necessary  to  observe  the  functioning  of  the  sensors  as  part  of 
an  ongoing  monitoring  of  overall  ATC  performance.  Second,  since 
the  DABS  sensors  operate  in  general  as  remote  unmanned  stations, 
it  is  important  to  continuously  monitor  the  existence  of  mal¬ 
functions  in  redundant  equipment  that  could  result  in  non- 
scheduled  maintenance  or  repair  activity.  The  messages  listed 
below  are  used  to  monitor  the  conditions  of  the  sensor  and 
related  activities.  These  messages  are  discussed  in  Section  5. 


Test  Response  Message 
Status  Message 

Track  Alert  Message  (Section  2.8.3) 


3.3.7  ATARS-to-ATC  Recording  System  Messages 

These  messages  are  discussed  in  the  ATARS  section  of  this 
document  (Section  4)  and  are  only  listed  here  for  completeness: 

ATARS  Recording  System  Messages  (Section  4.3.2) 

.  Duplicate  ATARS  Uplink  Message 
.  Duplicate  ATARS  Message  Delivery  Notice 

3.4  Example  of  ATC  Data  Link  Applications 

The  delivery  of  ATC  coordination  messages  is  chosen  as  an 
example  application,  since  these  messages  are  usually  highly 
structured  and  often  require  rapid  delivery  to  the  aircraft. 

This  type  of  data  link  application  lends  itself  to  Comm-A 
message  delivery  since  the  message  can  be  delivered  on  a 
priority  basis,  and  the  information  content  of  the  message  can 
be  encoded  within  the  available  message  field.  The  delivery  of 
two  different  coordination  messages,  the  Minimum  Safe  Altitude 
Warning  (MSAW)  Alerts  and  Altitude  Assignment  Clearance 
Confirmation,  using  the  DABS  data  link  will  be  discussed  in 
detail  in  the  following  sections.  It  should  be  noted  that  the 
following  sections  are  suggested  guidelines  for  the  use  of  the 
DABS  data  link,  and  that  they  only  reflect  example 
implementations  of  the  applications. 

3.4.1  Minimum  Safe  Altitude  Warning  (MSAW)  Alerts 

The  ARTS  III  processors  include  MSAW  algorithms  which  provide 
the  controller  with  a  visual  warning  and  an  aural  alarm  when 
tracked  Mode-C  equipped  aircraft  are  projected  to  violate 
altitude  criteria  programmed  into  the  ARTS  III  computer.  The 
DABS  data  link  extends  the  MSAW  capability  by  making  it  possible 
to  automatically  send  the  same  alert  to  DABS  data  link  equipped 
aircraft . 

Data  link  MSAW  messages  consist  of  two  messages  types.  One  is 
used  to  provide  the  MSAW  alert  and  the  second  to  clear  the 
alert.  The  MSAW  alert  message  contains  the  contraction  "MSAW" 
and  includes  the  minimum  safe  altitude  value,  in  feet,  in  the 
number  field.  This  message  is  delivered  to  the  aircraft  each 
scan  as  long  as  the  MSAW  alert  is  active.  When  the  MSAW  alert 
is  dropped,  a  clear-MSAW  message  is  delivered  to  the  aircraft  to 
clear  the  alert  from  the  cockpit  display.  In  the  event  that  the 


3-17 


clear-MSAW  message  is  not  received  by  the  aircraft,  the  airborne 
display  system  clears  the  MSAW  message  if  it  has  not  been 
updated  for  a  period  of  time  (e.g.,  15  seconds). 

When  an  alert  is  declared  and  is  not  inhibited  from  the  ARTS 
display  output  (e.g.,  inhibit  code  segment  or  controller 
keyboard  entry),  a  five  second  aural  alarm  is  sounded  in  the 
tower  cab/lFR  room  as  well  as  in  the  cockpit.  The  letters  "LAI*' 
indicating  "Low  Altitude  Alert  transmitted  to  the  pilot"  are 
displayed  blinking  in  field  "zero"  of  the  Full  Data  Block  (FDB) 
for  the  aircraft  involved  in  the  alert.  The  aircraft's  identity 
(ACID),  Mode  C  altitude,  and  "LAT"  are  displayed  in  the  MSAW 
display  area  of  the  ARTS  output  device.  When  an  alert  is 
declared  but  inhibited  from  the  ARTS  display  output,  the  MSAW 
alert  is  not  transmitted  to  the  pilot. 

When  the  alert  has  been  acknowledged  by  the  pilot  through 
keyboard  entry  the  aural  alarms  (if  still  active)  will  be 
terminated.  On  the  controllers  display  the  "LAT"  in  the  FDB  and 
in  the  MSAW  display  area  will  be  replaced  by  "ACK" 

(acknowledged) . 

3.4.2  Altitude  Assignment  Clearance  Confirmation 

The  Altitude  Assignment  Clearance  Confirmation  message  is  an 
uplink  message  to  the  cockpit  indicating  the  altitude  to  which 
the  En  Route  controller  has  cleared  the  aircraft.  The  message 
provides  the  pilot  with  a  visual  confirmation  of  the  standard 
voice  clearance  and  the  controller  with  a  visual  indication  of 
the  pilot's  "WILCO"  of  the  clearance.  The  Altitude  Assignment 
Confirmation  message  (transmitted  in  the  MA  field  of  a  Tactical 
Uplink  Message)  is  triggered,  for  a  controlled  DABS  track  in 
DABS  coverage,  by  a  controller's  manual  entry  of  an  assigned  (or 
interim)  altitude.  When  a  DABS-equipped  aircraft  is  eligible  to 
receive  this  message  a  "D"  will  be  displayed  to  the  controller 
in  the  FDB  (B5  character).  When  an  Altitude  Assignment 
Confirmation  is  sent  to  the  DABS  sensor  and  the  sensor  replies 
with  a  Message  Delivery  Notice,  indicating  that  the  message  was 
successfully  delivered  to  the  aircraft,  the  "D",  in  the  FDB  will 
be  replaced  with  an  "A"  indicating  "awaiting  the  pilot's 
WILCO".  Upon  receipt  of  the  WILCO  (received  in  the  MB  field  of 
a  Tactical  Downlink  Message),  the  "A"  will  be  replaced  with  a 
"W"  indicating  that  the  WILCO  has  been  received.  The  "W"  will 
be  displayed  for  a  short  time  period  before  reverting  again  to 
"D".  If  a  WILCO  is  not  received  within  a  timeout  period  after 
the  Message  Delivery  Notice  has  been  received,  the  "A"  will  also 
revert  to  a  "D". 
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The  altitude  clearance  message  is  typical  of  the  type  of  ATC 
coordination  message  which  does  require  quantitative  data  within 
the  message.  Besides  the  message  identifier,  the  specific 
altitude  value  associated  with  the  clearance  and  proper  message 
qualifiers  are  required. 

There  are  three  basic  qualifiers  associated  with  the  Altitude 
Assignment  Clearance  Confirmation.  These  are  "Maintain",  "Climb 
and  Maintain",  and  "Descend  and  Maintain."  The  assigned 
altitude  is  given  in  terms  of  either  "Flight  Level  (FL)",  or 
"Feet"  as  appropriate  for  the  particular  situation.  Examples  of 
message  text  displayed  to  the  pilot  are  "CAM  FL  260"  and  "MTN 
5000". 

3.5  Other  Data  Link  Applications 

Other  applications  of  the  DABS  data  link  are  now  under 
investigation.  As  experience  with  data  link  services  is  gained 
from  an  operational  DABS  system,  additional  applications  are 
likely.  At  present,  some  of  the  other  possible  data  link 
applications  are: 

.  Takeoff  Clearance  Confirmation 

.  Weather  Services 

.  Enhanced  Terminal  Information  Services 

.  Downlink  of  Airborne  Measurements 

Note:  Some  of  these  data  link  services  will  be  provided  by  a 

data  link  ground  system  not  involving  ATC  automation.  For 
example,  a  data  link  ground  system  could  provide  weather  data  to 
a  pilot  on  request  via  DABS. 


AUTOMATIC  TRAFFIC  ADVISORY  AND  RESOLUTION  SERVICE  (ATARS) 

4.1  ATARS-ATC  Facilities  Interface 

ATARS  is  a  totally  automated  ground-based  collision  avoidance 
system  which  provides  protection  to  aircraft  equipped  with  an 
ATARS  display  within  DABS  surveillance  coverage.  ATARS  provides 
separation  assurance  information  to  the  pilot  via  the  DABS 
airlink,  and  also  provides  alert  messages  to  the  controller  if  a 
potential  conflict  involves  a  controlled  aircraft.  In  this  way 
ATARS  will  be  a  backup  to  the  ATC  system's  separation  assurance 
role  for  ATARS  equipped  aircraft.  ATARS  is  designed  to  operate 
in  both  the  Terminal  and  En  Route  environments,  and  provides  the 
same  services  to  all  ATC  facilities.  However,  ATARS  can  be  site 
adapted  (Section  4.4)  to  the  needs  of  a  particular  ATC  facility. 

As  shown  in  Figure  4-1,  a  simplified  diagram  of  the  DABS 
Computer  Complex,  the  ATARS  function  is  part  of  the  complex  and 
is  located  at  the  DABS  site.  The  interface  between  ATARS  and 
the  ATC  facilities  consists  entirely  of  ATARS  sending 
operational  messages  and  recording  system  messages  (described  in 
Section  4.3)  via  the  two-way  ground  communications  link  between 
DABS  and  the  ATC  facilities.  ATC  software  accepts  these  inputs, 
interprets  them,  and  displays  the  appropriate  information  to  the 
controllers.  Terminal  and  En  Route  ATC  software  may  process 
ATARS  messages  differently  based  on  operational  requirements. 

In  the  cases  where  the  ATC  facility  is  also  operating  an 
independent  separation  assurance  system  (Terminal  or  En  Route 
Conflict  Alert)  the  ATC  software  combines  the  outputs  of  both 
systems  and  generates  messages  to  the  controller  which  contain 
all  the  useful  information. 

4.2  ATARS  Operation  Involving  Controlled  Aircraft 

ATARS  interacts  with  controlled  aircraft  to  accomplish  its 
function  of  providing  back-up  separation  assurance  services  by 
issuing  the  following  advisory  messages  as  required: 

1.  Proximity  advisories  -  to  advise  the  pilot  of  nearby 
(non-threat ing)  aircraft. 

2.  Threat  advisories  -  to  advise  the  pilot  of  potentially 
threatening  aircraft. 


3.  Negative  Resolution  Advisories  -  to  advise  the  pilot 
not  to  turn  in  a  particular  direction  or  to  limit  its 
vertical  speed. 


4.  Positive  Resolution  Advisories  -  to  provide  the  pilot 
with  the  recommended  collision  avoidance  maneuver. 

ATARS  interacts  with  the  ATC  facilty  whenever  a  conflict  or 
potential  conflict  exists  involving  at  least  one  controlled 
aircraft;  that  is,  ATARS  interacts  with  the  ATC  facility 
whenever  a  resolution  or  threat  advisory  is  sent  to  a  controlled 
aircraft.  This  interaction  takes  the  form  of  a  "Controller 
Alert  Message  with  Conflict  Resolution  Data"  at  the  time  a 
threat  advisory  is  issued,  and  the  form  of  a  "Resolution 
Notification"  at  the  time  a  resolution  advisory  is  issued. 

Table  4-1  depicts  the  time  relationship  of  ATARS  interaction 
with  pilots  and  controllers. 

The  ATARS  to  ATC  messages,  described  in  Section  4.3,  alert  the 
controller  to  the  conflict,  advise  him  of  the  suggested  ATARS 
conflict  resolution  data,  and  inform  him  of  the  status  of 
message  delivery  to  the  aircraft.  It  is  a  function  of  the  ATC 
facility  software  to  format  and  route  these  messages  to  the 
proper  device  for  display.  To  be  compatible  with  current 
operational  procedures  the  ATARS  controller  alerting  logic 
incorporates  the  basic  features  of  Terminal  Area  Conflict 
Alert.  ATARS  accounts  for  the  maneuvering  and  expected  close 
spacing  of  aircraft  in  the  terminal  area.  Thus,  protection  is 
provided  to  controlled  aircraft  in  predefined  maneuvering, 
landing,  and  takeoff  areas  from  other  aircraft  in  the  area  not 
following  accepted  operating  procedures.  A  reduction  in  the 
number  of  "unnecessary  alarms"  is  accomplished  by  mapping  the 
geographical  areas  around  the  airports  in  which  these  operations 
normally  occur.  This  feature  provides  conflict  protection  but 
allows  normal  in-line  following  and  parallel  paths  that  would 
occur  in  take-off  and  landing  operations.  (In  the  En  Route 
environment  these  ATARS  features  are  not  normally  exercised.) 

ATARS  uses  different  conflict  thresholds  (lead  times)  depending 
on  whether  the  aircraft  are  under  ATC  control  or  uncontrolled. 
Therefore,  ATARS  should  be  informed  of  all  aircraft  under  ATC 
control.  This  information  is  passed  to  ATARS  through  DABS  by 
ATC's  initiation  of  an  Aircraft  Control  State  Message  (Section 
5.2.6). 

4.2.1.  Controlled/Uncontrolled  Encounters 

ATARS  attempts  to  resolve  conflict  situations  between  controlled 
and  uncontrolled  aircraft  by  maneuvering  the  uncontrolled 


aircraft  first.  Only  if  the  resolution  advisory  to  the 
uncontrolled  aircraft  fails  to  resolve  the  encounter  will  ATARS 
issue  a  resolution  advisory  to  the  controlled  aircraft. 


At  the  time  a  threat  advisory  is  issued  to  the  aircraft  involved 
in  the  potential  conflict,  a  "Controller  Alert  Message  with 
Conflict  Resolution  Data  (Section  4.3. 1.1)  is  issued  by  ATARS  to 
the  ATC  facility.  This  message  alerts  the  controller  to  the 
potential  conflict  and  provides  Conflict  Resolution  Data 
pertaining  only  to  the  uncontrolled  aircraft.  The  Conflict 
Resolution  Data  represents  the  resolution  advisory  that  ATARS 
would  issue  to  the  uncontrolled  aircraft  if  it  were  to  issue  one 


at  the  time  of  the  threat  advisory.  The  Conflict  Resolution 
Data  can,  therefore,  be  thought  of  as  a  preview  of  the 
resolution  advisory  that  ATARS  will  issue  if  the  geometry  of  the 
encounter  remains  the  same  as  the  aircraft  converge.  The 
controller  observes  the  warning  and  may  elect  to  maneuver  the 
controlled  aircraft  to  avoid  the  uncontrolled  aircraft  or  issue 
an  advisory  on  the  traffic. 

If  the  potential  conflict  continues  to  develop  ATARS  will  issue 
a  resolution  advisory  to  the  uncontrolled  aircraft  and  will 
initiate  a  "Resolution  Notification"  message  (Section  4. 3. 1.2) 
to  the  ATC  facility  indicating  the  resolution  advisory  issued  to 
the  uncontrolled  aircraft.  The  controller  is  now  aware  that  the 
indicated  resolution  advisory  has  been  sent  to  the  uncontrolled 
aircraft.  At  a  later  time  if  the  potential  conflict  has  still 
not  been  resolved,  ATARS  takes  a  final  step,  which  is  the 
issuance  of  a  resolution  advisory  to  the  controlled  aircraft  and 
the  issuance  of  the  Resolution  Notification  to  the  ATC  facility 
to  indicate  that  a  resolution  advisory  has  been  sent. 

4.2.2  Controlled/Controlled  Encounters 


For  encounters  in  which  both  aircraft  are  under  ATC  control, 
ATARS  is  intended  to  serve  as  a  last-instant -back-up  system.  It 
is  not  intended  to  supplant  the  ATC  system  or  routinely  maneuver 
controlled  aircraft.  Its  operation  is  very  similar  to  the 
previously  discussed  encounter  and  the  controller! s)  are 
informed  of  ATARS  actions  through  the  Controller  Alert  Messages 
except  that  the  Conflict  Resolution  Data  provided  within  the 
Controller  Alert  Messages  now  pertains  to  the  controlled 
aircraft  and  hence  can  be  used  by  the  controller  as  an  aid  in 
selecting  some  controller  action  if  deemed  appropriate. 


4.3  ATARS-to-ATC  Messages 


The  messages  generated  by  ATARS  for  delivery  via  the  DABS 
groundlink  to  ATC  facilities  are  of  two  distinct  types, 
operational  and  recording  system  messages,  each  of  which  is 
discussed  in  the  following  sections. 

4.3.1  Controller  Alert  Message 

ATARS-to-ATC  operational  messages  can  be  classified  as 
"Controller  Alert  Messages."  They  advise  the  controller  of  the 
state  of  potential  conflict  between  two  aircraft  or  between  an 
aircraft  and  an  obstacle,  restricted  airspace,  or  the  terrain. 
For  a  Controller  Alert  Message  to  be  issued  at,  least  one 
aircraft  involved  in  the  potential  conflict  must  be  under  ATC 
control.  When  a  potential  conflict  involves  more  than  two 
aircraft,  ATARS  will  issue  a  separate  Controller  Alert  Message 
for  each  pair.  ATARS  will  continue  to  issue  a  Controller  Alert 
Message  as  long  as  ATARS  determines  that  conditions  warrant  the 
attention  of  the  controller. 

Functionally,  a  Controller  Alert  Message  can  be  interpreted  as 
having  five  states:  (1)  Conflict  Resolution  Data,  (2) 

Resolution  Notification  (3)  Terrain  Avoidance,  (4)  Obstacle 
Avoidance,  and  (5)  Restricted  Airspace  Avoidance,  each  of  which 
will  be  discussed  in  the  following  sections.  The  data  block 
format  of  the  Controller  Alert  Message  (References  1  and  6) 
contains:  an  8-bit  message  type,  the  DABS  ID  or  ATCRBS  Mode  3/A 
code  plus  Surveillance  File  Number  for  each  aircraft  involved  in 
the  potential  conflict,  the  control  status  and  equippage 
(DABS/ATCRBS)  of  each  aircraft,  resolution  fields  containing  the 
ATARS  resolution  advisory  for  each  aircraft,  and  delivery  status 
of  the  resolution  advisories. 

4.3. 1.1  Conflict  Resolution  Data 

If  ATARS  projects  a  potential  conflict  with  another  aircraft 
within  a  predetermined  lead  time,  the  ATC  facilities  responsible 
for  those  aircraft  will  be  alerted  to  the  problem  (Reference  6) 
by  generation  of  a  Controller  Alert  Message  with  Conflict 
Resolution  Data.  (If  the  ATC  facility  is  equipped  with  its  own 
conflict  alert  capability,  the  ATC  software  must  be  designed  to 
handle  the  receipt  of  both  messages.)  For  this  message  the 
delivery  status  fields  would  indicate  that  this  message 
contained  preliminary  conflict  resolution  data  and  that  ATARS 


had  not  attempted  delivery  to  the  aircraft  involved.  The 
message's  resolution  fields  contain  the  ATARS  resolution 
advisories  which  would  be  issued  by  ATARS  if  it  were  to  resolve 
the  potential  conflict  at  this  time. 

4.3 . 1.2  Resolution  Notification 


If  a  conflict  (involving  at  least  one  controlled  aircraft) 
progresses  to  a  more  serious  stage,  ATARS  will  generate  for 
uplink  transmission,  resolution  advisories  for  the  DABS  equipped 
aircraft,  and  at  the  same  time  send  the  responsible  ATC  facility 
an  alert  message.  The  message's  resolution  fields  contain  the 
ATARS  resolution  advisories  issued  to  each  aircraft  with 
delivery  status  fields  indicating  that  delivery  has  been 
completed,  or  is  currently  being  attempted. 

4.3. 1.3  Terrain  Avoidance 


If  ATARS  projects  a  potential  conflict  of  a  controlled  aircraft 
with  the  terrain  within  a  predetermined  lead  time,  the 
responsible  ATC  faiclity  will  be  alerted  to  the  potential 
problem  by  the  generation  of  a  message  indicating  a  Terrain 
Avoidance  alert.  At  the  same  time  the  pilot  will  be  issued  a 
Terrain  Avoidance  Advisory  by  ATARS. 

4.3. 1.4  Obstacle  Avoidance 


If  ATARS  projects  a  potential  conflict  of  a  controlled  aircraft 
with  an  aerial  obstacle  within  a  predetermined  lead  time,  the 
responsible  ATC  facility  will  be  alerted  to  the  potential 
problem  by  the  generation  of  a  message  indicating  an  Obstacle 
Avoidance  alert.  At  the  same  time  the  pilot  will  be  issued  an 
Obstacle  Avoidance  Advisory  by  ATARS. 

4.3. 1.5  Restricted  Airspace  Avoidance 

If  ATARS  projects  that  a  controlled  aircraft  will  be  penetrating 
unauthorized  airspace  within  a  predetermined  lead  time,  the 
responsible  ATC  facility  will  be  alerted  to  the  problem  by  the 
generation  of  a  message  indicating  a  Restricted  Airspace 
Avoidance  alert.  At  the  same  time  the  pilot  is  being  issued  an 
advisory  by  ATARS. 

4.3.2  ATARS  Recording  System  Messages 

For  administrative  reasons,  it  is  necessary  to  make  a  complete 
recording  of  ATARS-generated  transactions.  The  recording  system 
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for  these  messages  will  be  located  at  the  ATC  facilities  and  in 
the  case  of  multi-site  DABS  configurations  certain  ATC 
facilities  would  house  the  recording  system  for  more  than  one 
DABS  site.  Two  types  of  messages  are  transmitted  from  DABS  for 
recording  purposes.  Details  of  these  messages  follow. 

4. 3 .2.1  Duplicate  ATARS  Uplink  Message 

A  "Duplicate  ATARS  Uplink  Message"  iB  generated  by  the  ATARS 
processor  for  transmission  to  the  ATC  facility  whenever  an  ATARS 
tactical  uplink  is  generated  for  transmission  to  an  aircraft. 
Note  that  advisories  that  are  not  actually  transmitted,  such  as 
those  for  non-DABS  equipped  aircraft,  are  not  included.  The 
format  of  a  Duplicate  ATARS  Uplink  Message,  except  for  the  8-bit 
type  code,  is  precisely  that  of  the  ATARS-generated  tactical 
uplink  message  that  it  duplicates.  The  DABS  sensor,  upon 
receipt  of  this  message,  routes  it  to  the  appropriate  ATC 
facility  which  in  turn  routes  the  message  to  the  ATARS  recording 
system. 

4. 3. 2. 2  Duplicate  ATARS  Message  Delivery  Notice 

A  "Duplicate  ATARS  Message  Delivery  Notice"  provides  for  the 
recording  of  the  technical  acknowledgement /delivery  failure  of 
an  ATARS  uplink  message.  This  type  of  message  is  generated 
within  the  DABS  sensor  which  attempts  uplink  delivery,  rather 
than  within  the  ATARS  function  itself. 

The  message  format  is  that  of  an  ordinary  message  delivery 
notice,  but  with  the  addition  of  a  "referenced  sender  ID" 
field.  This  field  contains  the  sensor  ID  code  of  the 
originating  ATARS.  It  will,  therefore,  match  the  implicit 
sensor  code  of  the  duplicate  ATARS  uplink  message.  This  match, 
together  with  a  match  between  the  explicit  "message  number"  and 
the  "reference  message  number",  enables  message  association. 

The  DABS  sensor  generates  the  duplicate  delivery  notice  and 
routes  it  to  the  appropriate  ATC  facility  at  the  same  time  that 
it  generates  an  ordinary  delivery  notice  and  routes  it  to  the 
originating  ATARS.  Upon  receipt,  the  ATC  facility  routes  the 
message  to  the  ATARS  recording  system. 


The  ATARS  fir  ction  located  at  each  DABS  sensor  uses  both  the 
surveillance  and  data  link  capabilities  of  the  network  of 
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sensors  (to  which  it  may  be  netted)  to  effect  separation 
assurance  of  aircraft  currently  under  surveillance.  The  nominal 
ATARS  range  is  90  nmi  for  horizontal  resolution  advisories, 
beyond  this  range  resolution  advisories  will  be  limited  to  the 
vertical  dimension  due  to  increased  errors  in  horizontal 
position  and  velocity  estimates.  However  the  particular  areas 
of  airspace  for  which  ATARS  services  (traffic,  and  resolution 
advisories)  are  provided  at  a  site  are  dependent  on  many  factors 
such  as  on  geographical  constraints,  the  location  of  adjacent 
DABS  sensors  (if  any),  the  number  and  types  of  ATC  facilities 
being  serviced,  and  the  linking  of  the  adjacent  DABS  sensors  by 
ground  lines  (netting).  Within  ATARS  there  are  many  features 
which  allow  the  separation  assurance  system  to  be  adapted  to  the 
particular  site  configuration.  These  features  provide 
additional  services  such  as  restricted  airspace  avoidance,  and 
prevent  high  "unnecessary  alarm"  rates  due  to  standard  traffic 
patterns  in  the  ATARS  coverage  area. 

4.4.1  ATARS  Service  Zone  Map 

In  the  case  of  a  single  DABS  sensor  providing  surveillance  for 
an  isolated  volume  of  airspace  the  ATARS  Service  Zone  is  simply 
defined  as  the  DABS  coverage  area.  (This  definition  is  also 
true  for  adjacent  sensors  whose  nominal  ATARS  Service  Zones 
don't  overlap.)  Within  a  range  dependent  on  DABS  surveillance 
accuracy  (nominally  90  nmi)  ATARS  will  provide  full  conflict 
resolution  service.  Beyond  this  range  resolution  advisories 
will  be  limited  to  the  vertical  dimension  due  to  increased 
errors  in  horizontal  position  and  velocity  estimates. 

Interior  to  the  ATARS  service  zone  is  a  boundary,  the  BCAS 
Service  Zone  boundary,  at  which  the  airborne  collision  avoidance 
system  known  as  the  Beacon  Collision  Avoidance  System  (BCAS)  is 
not  allowed  to  perform  active  interrogations.  As  shown  in 
Figure  4-2  the  height  of  the  floor  of  this  boundary  is 
established  sufficiently  above  the  DABS  coverage  floor  so  that 
BCAS  would  provide  protection  against  any  aircraft  climbing  at 
reasonable  rates  from  below  the  coverage  floor.  Likewise,  the 
position  of  the  BCAS  active  interrogation  boundary  in  range  is 
established  so  that  BCAS  protects  against  threats  with 
reasonable  speeds  approaching  from  beyond  the  ATARS  service  zone 
range  boundary. 


In  the  cases  of  multiple  DABS  sites,  with  overlapping  ATARS 
Service  Zones,  another  method  of  constructing  the  ATARS  service 
zone  boundaries  must  be  used.  First,  a  nominal  ATARS  service 
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FIGURE  4-3 

ATARS  BOUNDARIES  AND  SEAM  AREA 


boundary  (see  Figure  4-3),  must  be  chosen  which  provides 
division  of  ATARS  conflict  resolution  responsibility  for  pairs 
of  aircraft  between  the  two  DABS  sites.  (Location  of  this 
boundary  is  dependent  on  expected  site  loading  and  local  terrain 
features,  e.g.,  for  sites  with  equal  expected  loads,  the 
boundary  could  be  placed  at  the  intersection  of  the  floor  of 
coverage  of  the  two  sensors.)  For  ATARS  to  assure  conflict 
resolution  service  to  pairs  of  aircraft  straddling  this 
boundary,  a  seam  area  of  overlapping  coverage  is  created  across 
this  boundary.  The  width  of  this  seam  is  chosen  to  allow  timely 
detection  of  conflicts  across  the  nominal  boundary,  plus  a  small 
increment  to  account  for  registration  errors  between  the  two 
sensors'  perception  of  that  boundary. 

The  ATARS  logic  and  coordination  between  the  adjacent  ATARS 
determines  uniquely  which  site  will  be  responsible  for  a 
conflict  that  occurs  in  this  seam  area.  However,  the  choice  of 
the  ATARS  site  ID's  will  determine  the  edge  of  the  seam  at  which 
the  "logical  boundary"  will  be  placed.  (Note:  This  is  not  the 
DABS  site  ID,  the  only  valid  ATARS  site  ID's  are  0001,  0010, 
0100,  1000).  As  shown  in  Figure  4-3,  the  "logical  boundary"  is 
always  the  edge  of  the  seam  nearest  the  site  with  the  lowest 
ATARS  site  ID.  In  general  the  site  with  the  higher  ID  resolves 
conflicts  on  its  side  of  the  logical  boundary,  and  the  site  with 
the  lower  ID  solves  conflicts  on  its  side,  as  well  as  those  with 
one  aircraft  on  its  side  and  one  in  the  seam  area.  Figure  4-4 
is  an  example  of  possible  ATARS  service  zones  for  the  Los 
Angeles  Basin. 

Additional  ATARS  Service  Zone  Maps  must  be  created  to  account 
for  the  reconfiguration  of  the  local  ATARS  Service  Zone  in  the 
event  of  the  failure  of  an  adjacent  DABS  sensor.  As  a  minimum  a 
map  for  normal  operation  (no  sensor  failure)  and  one  for  each 
possible  configuration  with  one  adjacent  sensor  failed  need  be 
developed  for  each  DABS  site. 

4.4.2  BCAS  Performance  Level  Control  Map 

To  insure  that  ATARS  reolves  all  potential  conflicts  with  ATCRBS 
aircraft  within  the  ATARS  Service  Zone,  the  intersection  of  the 
ATARS  Service  Zone  and  the  BCAS  Service  Zone  (shown  in  Figure 
4-2)  must  be  mapped.  The  BCAS  Performance  Level  Control  Map 
performs  this  function  and  is  created  in  the  following  manner. 
First  the  area  of  intersection  is  mapped  into  zones  and  is 
defined  as  the  BCAS  Performance  Control  Area.  Within  this  area 
smaller  zones  are  inserted  to  define  areas  of  different  BCAS 
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performance  levels.  These  smaller  zones  represent  the 
intersections  of  the  BCAS  Performance  Control  Area  with  the 
various  ATARS  Area  Types  defined  in  the  ATARS  Area  Type  Map. 

4.4.3  ATARS  Area  Type  Map 

To  reduce  unnecessary  alarms  around  the  airport  and  airport 
approaches,  ATARS  provides  for  the  establishment  of  airport  area 
types.  ATARS  conflict  detection  considers  the  airport  area  type 
in  determining  the  appropriate  separation  criteria  and  detection 
logic  to  be  employed. 

To  achieve  these  goals  it  is  necessary  that  an  ATARS  "Area  Type 
Map"  be  created  for  each  airport.  This  would  basically  consist 
of  defining  the  airspace  in  which  certain  operations  (which 
contribute  to  unnecessary  alarms)  occur.  The  separation 
criteria  in  each  of  these  area  types  is  site  adaptable  allowing 
ATARS  to  be  "tuned"  for  each  airport. 

The  ATARS  detection  logic  allows  for  four  different  area  types, 
with  Area  Type  4  having  the  largest  protection  volume,  and  Area 
Type  1  having  the  smallest.  Area  Type  1  encompasses  the 
iranediate  vicinity  of  an  airfield  and  is  defined  as  a  "right 
parallelpiped" .  Area  Type  1,  however,  may  be  modified  with 
"legs"  or  straight  line  segments  that  may  be  used  to  remove 
corners  of  the  parallelpiped.  Area  Type  2  encompasses  approach 
areas  for  each  runway  between  specified  altitudes  and  is  also 
defined  as  a  right  parallelpiped.  As  part  of  the  definition  of 
Area  Types  1  and  2,  minimum  and  maximum  altitudes  must  be 
specified.  Area  Type  3  is  the  balance  of  airspace  within  a 
cylinder  whose  base  is  centered  on  the  airport  and  has  a  radius 
equal  to  a  site  selectable  value  of  range.  All  airspace  beyond 
Area  Type  3  is  defined  as  Area  Type  4.  Figure  4-5  gives  an 
example  of  a  two-dimensional  representation  of  area  types  around 
an  airport.  For  Area  Types  1  and  2  the  value  of  a  site 
adaptable  parameter  determines  whether  or  not  "controller 
alerts"  will  be  generated  for  conflicts  occurring  within  these 
areas . 


4.4.4  ATARS  Final  Approach  Zone  Map 

Another  feature  of  ATARS,  which  is  site  adaptable,  is  the 
definition  of  the  "Final  Approach  Zone  Map".  The  Final  Approach 
Zone  (FAZ)  is  a  volume  of  airspace  in  which  ATARS  is  inhibited 
from  transmitting  resolution  advisories  (pertaining  to  potential 
conflicts  totally  within  the  FAZ)  to  an  aircraft.  Basically, 
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FIGURE  4-5 

EXAMPLE  OF  ATARS  AREA  TYPE  MAP 
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the  Final  Approach  Zone  is  divided  into  two  types,  type  1 
encompassing  the  airfield  (and  generally  to  a  lower  altitude 
than  for  Area  Type  1),  and  type  2,  encompassing  a  sloping 
rectangular  region  containing  the  normal  approach  path  for  each 
runway,  see  Figure  4-6. 

4.4.5  ATARS  Restricted  Airspace  Map 

In  order  for  ATARS  to  provide  "Restricted  Airspace  Alerts"  both 
to  pilots  and  to  controllers  (if  controlled  aircraft  are 
involved),  it  is  necessary  that  for  each  DABS/ATARS  site  a 
Restricted  Airspace  Map  be  created.  The  map  defines  each  volume 
of  airspace  that  is  restricted  within  the  ATARS  service  zone  and 
identifies  each  as  to  the  type  of  restriction  (TCA's,  restricted 
military  areas,  etc.).  The  coded  identity  of  each  volume  will 
enable  ATARS  to  generate  the  proper  alerts,  such  as  "Restricted 
Airspace  Entered"  to  the  pilot  and  "ABC462  Has  Entered 
Restricted  Airspace"  to  the  controller. 

4.4.6  ATARS  Terrain  Elevation  Map 

The  ATARS  Terrain  Avoidance  function  is  dependent  upon  the 
definition  of  an  ATARS  "Terrain  Elevation  Map"  for  each 
DABS/ATARS  site.  Since  the  effectiveness  of  a  terrain  avoidance 
system  (safety  without  excessive  unnecessary  alarms)  is  heavily 
dependent  upon  the  quality  of  the  terrain  map,  the  ATARS 's 
Terrain  Elevation  Map  incorporates  features  which  allow  high 
resolution.  Figure  4-7  shows  that  a  variable  cell  size 
structure  is  used.  As  shown  in  the  picture,  geographical 
locations  with  large  changes  in  altitude  over  a  small  area  would 
be  mapped  with  many  small  cells.  Locations  with  relatively 
constant  altitude  over  larger  areas  would  be  mapped  with  fewer 
larger  cells. 

4.4.7  ATARS  Obstacle  Avoidance  List 


In  order  for  ATARS  to  provide  "Obstacle  Avoidance  Alerts"  both 
to  pilots  and  controllers,  it  is  necessary  that  for  each 
DABS/ATARS  site  a  list  of  the  position  and  height  of  each 
obstacle  (radio  towers,  skyscrapers,  etc)  within  the  ATARS 
service  zone  be  created.  ATARS  then  performs  obstacle  conflict 
detection  for  all  aircraft  within  the  service  zone,  and 
generates  alerts  to  pilots  and  controllers  (if  controlled 
aircraft  are  involved)  indicating  the  presence  of  a  near 
obstacle. 


4-17 


FIGURE  4-7 

EXAMPLE  OF  ATARS  TERRAIN  ELEVATION  MAP 


4.4.8  Diffraction  Zone  Ma 


Azimuth  degradation  due  to  diffraction  around  obstructions  on 
the  skyline  has  been  shown  to  be  a  significant  problem  for 
ATARS.  While  data  link  contact  can  be  maintained  in  these 
areas,  the  azimuth  errors  in  some  cases  are  so  great  as  to 
preclude  ATARS  service.  Therefore,  a  map  will  be  maintained 
that  can  indicate  when  a  target  is  in  an  area  of  known 
diffraction  effects.  The  information  required  for  this  map  is 
the  azimuth  of  obstructions  and  elevation  angle  below  which 
diffraction  occurs. 

4.5  Operational  Considerations  for  Areas  of  Overlapping 
Terminal  and  En  Route  Sensors 


To  insure  that  ATARS  provides  separation  assurance  in  areas  of 
overlapping  terminal  and  en  route  sensors  additional  factors 
must  be  considered.  First,  in  the  development  of  the  ATARS 
Service  Zone  Maps  (Section  4.4.1)  for  each  site,  the  ATARS 
multi-site  seam  area  must  be  sufficiently  wide  to  preclude  a 
conflict  from  occurring  across  the  seam  as  shown  in  Scenario  A 
in  Figure  4-8.  The  ATC  handoff  seam  is  defined  as  the  volume  of 
airspace  in  which  aircraft  handoff  between  Terminal  and  En  Route 
ATC  facilities  normally  occurs  plus  additional  airspace  for  late 
and  early  handoff.  Next,  the  location  of  the  ATARS  multi-site 
seam  is  adjacent  to  the  ATC  handoff  seam  and  is  always  on  the 
side  of  the  En  Route  coverage  area.  It  should  be  noted  that 
both  horizontal  and  vertical  seams  are  defined  (see  Figure 
4-8.).  The  ATARS  connected  to  the  terminal  facility  will  be 
responsible  for  all  conflicts  which  occur  in  the  handoff  seam 
and  will  generate  the  appropriate  advisories  to  the  aircraft, 
and  controller  alerts  to  the  ARTS  facility.  Upon  receipt,  the 
Terminal  ATC  facility  relays  a  duplicate  of  the  Controller  Alert 
Message  to  the  En  Route  facility  sharing  the  handoff  seam  via 
the  interfacility  link  between  the  Terminal  and  En  Route 
facilities.  If  the  En  Route  facility  is  controlling  at  least 
one  of  the  aircraft,  the  Resolution  Notification  is  displayed  by 
the  ATC  computers  to  the  controller.  In  the  case  where  neither 
aircraft  are  controlled  by  the  En  Route  facility  the  En  Route 
computers  discard  the  message. 
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STATUS  AND  CONTROL 


5.1  General 


The  DABS  sensor  is  designed  such  that,  when  deployed, 
maintenance  personnel  need  not  be  stationed  at,  or  near,  the 
sensor.  To  support  this  "unmanned”  maintenance  concept,  the 
DABS  sensor  will  interchange  certain  status  and  control 
messages  with  the  connected  ATC  facilities,  and  when 
implemented,  the  Remote  Maintenance  Monitor  System  (RMMS).  The 
effect  of  these  messages  will  be  twofold:  (1)  indicate  sensor 
performance  to  maintenance  personnel  for  appropriate  action  and 
(2)  support  failure  and  recovery  mode  processing  in  order  that 
surveillance,  communications  and  ATARS  services  will  continue, 
to  the  maximum  extent  possible,  in  the  event  of  sensor  or  ATC 
facility  failure  (and  recovery  from  failure). 

In  addition,  certain  messages  will  be  sent  from  the  ATC 
facilities  to  the  DABS  sensors  to  indicate  control  information 
needed  for  the  normal  operation  of  surveillance,  communications 
and  ATARS  services. 

Following  is  a  description  of  the  status  and  control  messages 
which  will  be  transmitted  between  the  DABS  sensor  and  the  ATC 
facility. 

5.2  Status  and  Control  Messages 
5.2.1  Sensor  Status  Message 

Each  DABS  sensor  issues  a  Status  Message  once  per  antenna  scan 
period  to  each  ATC  Facility  (or  RMMS)  to  which  it  is  linked. 
(The  format  of  this  message  is  defined  in  Reference  1,  and  its 
information  contents  are  specified  in  Reference  2.) 
Determination  of  sensor  status  is  the  task  of  the  Performance 
Monitoring  function  within  each  sensor.  Performance  Monitoring 
will  regularly  perform  many  tests  on  the  operation  of  other 
functions  within  the  sensor,  both  hardware  and  software.  For 
example,  software  checks  will  include  overflow  status  of 
various  queues  and  buffers,  and  the  number  of  uplink  messages 
delivered  and  expired.  Among  the  hardware  parameters  checked 
will  be  transmitter  peak  power. 
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In  addition,  inputs  will  be  included  from  Calibration  and 
Performance  Monitoring  Equipments  (CPMEs).  These  are 
transponder- like  devices  at  known  ground  locations. 

CPME  replies  will  provide  a  check  on  software  and  hardware 
relating  to  uplink  modulation  and  transmission,  downlink  reply 
processing,  and  data  link  and  surveillance  processing, 
including  position  measurement  calibration  and  surveillance 
report  accuracy.  All  of  these  inputs  will  enter  into  a 
determination  of  the  sensor  status  category  (normal  operation, 
marginal  operation,  or  failure).  The  status  category  will  also 
be  issued  by  the  sensor  to  adjacent  connected  DABS  sensors. 

(In  most  cases  the  ATC  facility  will  control  sensor 
reconfiguration  by  issuance  of  a  Sensor  Failure/Recovery 
Message,  Section  5.2.5).  A  failure  status  will  cause  the 
sensors  notified  to  modify  their  surveillance/communications 
coverage  areas  and  ATARS  responsibility  areas  in  a 
predetermined  manner  so  as  to  take  over  (in  regions  of 
overlapping  coverage)  for  the  failed  sensor. 

The  types  of  information  which  will  be  included  in  a  Status 
Message  ares  sensor  loading  statistics  (the  number  of  DABS, 
ATCRBS  and  radar-only  tracks),  the  status  category  of  the 
sensor  and  its  associated  ATARS  function  and  the  specific 
conditions  that  resulted  in  any  declaration  of  marginal  or 
failed  status.  During  non-normal  status,  the  particular 
problem  areas  will  be  indicated  in  the  message.  Status 
messages  sent  to  the  ATC  facilities  will  be  routed  to  the 
output  device  of  the  responsible  personnel.  A  flag  contained 
in  the  message  will  indicate  whether  the  current  message  has 
changed  from  the  one  sent  in  the  previous  scan.  This  feature 
will  allow  the  ATC  facility  software  to  print  only  the  messages 
which  will  have  "change"  indicated. 

5.2.2  Test  Message 

A  "Test  Message"  and  the  resulting  response  will  comprise  a 
transaction  that  can  be  initiated  by  an  ATC  facility.  The 
message  format  will  simply  contain  the  8-bit  message  identifier 
and  a  48  bit  free  text  field.  A  test  transaction  will  serve  to 
verify  proper  operation  of  the  ground  communications  link  and 
sensor  software  such  as  message  routing  and  test  response. 
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5.2.3  Test  Re s ponse  Message 


The  "Test  Response  Message"  will  be  issued  by  the  sensor  in 
response  to  a  Test  Message.  Its  data  format  will  consist  of  an 
8-bit  message  identifier,  and  a  48-bit  free  text  field  which 
upon  proper  operation  will  echo  the  data  sent  in  the 
corresponding  "Test  Message". 

5.2.4  ATC  Failure/Recovery  Message 

The  ATC  Failure/Recovery  message  is  used  to  inform  a  DABS 
sensor  and  collocated  ATARS  of  a  change  in  operational  status 
of  a  ATC  facility.  Its  text  will  contain  a  message  identifier 
along  with  a  2-bit  data  block  that  indicates  failure,  recovery 
from  failure,  or  recovery  from  failure  with  loss  of  data  base. 

When  a  sensor  is  notified  of  an  ATC  facility  failure  the 
dissemination  map  of  the  sensor  will  be  reconfigured  to  a  new 
dissemination  map  based  on  the  remaining  ATC  facilities 
connected  in  order  for  these  facilities  to  provide  backup 
operations.  When  a  sensor  is  notified  of  the  ATC  recovery,  the 
dissemination  map  will  be  restored  to  its  original 
conf igurat ion. 

5.2.5  Sensor  Failure/Recovery  Message 

The  Sensor  Failure/Recovery  Message  will  be  initiated  by  the 
ATC  facility  (or  RMMS)  upon  determination  of  a  change  in  the 
status  (failure/recovery)  of  a  particular  DABS  sensor  or 
sensor-to-sensor  communications  link.  This  message  will  be 
sent  to  all  other  DABS  sensors  sharing  overlapping  coverage 
with  the  particular  sensor  changing  status.  The  receipt  of 
this  message  by  a  DABS  sensor  may  initiate  reconfiguration  of 
the  sensor's  coverage  area  and  area  of  Primary  status.  The 
contents  of  the  message  will  include  the  ID  of  the  DABS  sensor 
being  reported  and  the  status  (failure  or  recovery)  of  the 
sensor  or  the  sensor-to-sensor  communications  link. 

5.2.6  DABS  and  ATCRBS  Aircraft  Control  State  Messages 

The  Aircraft  Control  State  (ACS)  Messages  are  sent  by  the  ATC 
facility  to  indicate  to  DABS  sensors  which  aircraft  (DABS  and 
ATCRBS)  are  under  control  of  an  ATC  facility.  The  message  will 
also  be  used  to  notify  a  DABS  sensor  of  its  Primary /Secondary 
status  with  respect  to  a  controlled  DABS  aircraft.  The  assign¬ 
ment  of  Primary/Secondary  status  using  the  ACS  message  is 
discussed  in  Section  5.3. 
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The  DABS  ACS  message  format  consists  of  the  8-bit  message  type, 
an  "index"  field  indicating  the  number  of  aircraft  referenced  in 
the  message  for  each  aircraft  control  state  and  the  DABS  Address 
for  each  aircraft. 

The  ATCRBS  ACS  message  format  consists  of  the  8-bit  message 
type,  an  "index"  field  indicating  the  number  of  controlled  and 
uncontrolled  aircraft  referenced  in  the  message  and  the  Mode  3/A 
code  and  SFN  for  each  aircraft. 


5.2.7  Altimeter  Correction  Message 

The  altimeter  correction  message  is  generated  by  an  ATC  facility 
to  provide  altimeter  corrections  to  DABS  equipped  aircraft  in 
particular  geographic  areas  based  on  changes  in  barometric 
pressure  for  those  areas.  This  message  is  used  to  support  the 
ATARS  terrain  avoidance  function  and  the  DABS  altitude  echo 
(ALEC)  feature.  The  message  contains  the  barometric  pressure 
correction  (in  hundreds  of  feet)  for  a  particular  area.  The 
number  of  such  correction  blocks  in  a  message  and  the  geographic 
interpretation  of  each  correction  is  predetermined  for  a 
particular  ATC  facility-DABS  sensor  pair. 

5.2.8  Track  Alert  Message 

This  message,  reporting  the  detection  of  two  aircraft  with  the 
same  DABS  Address,  is  discussed  in  section  2.8.3  and  is  listed 
here  only  for  completeness. 

5.3  Primary/Secondary  Assignment 

Regardless  of  whether  the  sensors  are  netted  or  non-netted,  the 
Network  Management  funci  ion  in  each  sensor  (see  Reference  3) 
will  coordinate  the  network  of  DABS  sensors  to  insure  adequate 
surveillance  and  communications  in  areas  of  common  coverage. 
Included  in  this  function  will  be  a  task  involving  the 
cooperative  management  among  sensors  and  the  ATC  facilities  to 
which  they  are  connected  to  assure  that  for  a  given  DABS-equipped 
aircraft  at  a  given  time,  only  one  sensor  will  be  designated  as 
"Primary".  Among  the  DABS  sensors,  Primary  status  means  that 
only  that  sensor  will  be  permitted  to  carry  out  certain 
exclusive  functions  related  to  the  particular  DABS-equipped 
aircraft.  These  functions  include  the  readout  of  pilot- 
originated  downlink  messages,  the  uplink  of  ground-originated 
ELM's,  uplink  of  ATARS  Traffic  Service  Advisories  (Reference  6), 
and  the  management  of  DABS  transponder  lockout.  Other  sensors 


extending  coverage  to  the  aircraft  will  be  designated 
"Secondary".  Limited  regions  of  dual  Primary  assignments  for 
an  aircraft  may  exist  and  be  acceptable  under  certain 
circumstances  between  non-netted  sensors.  However,  within  the 
DABS  coverage  area,  regions  of  airspace  where  no  sensor  is 
designated  as  Primary  for  an  aircraft  will  not  be  permitted 
since  the  necessary  functions  pertaining  to  Primary  status  will 
not  be  performed. 

Primary/Secondary  (P/S)  status  may  be  unambiguously  determined 
and  maintained  solely  from  information  contained  in  each  cell 
of  the  sensor's  adapted  coverage  map,  and  sensor-to-sensor 
protocol.  However,  when  data  link  services  are  introduced  into 
the  ATC  system  and  sensor  deployment  results  in  considerable 
coverage  overlap  it  will  be  necessary  for  the  ATC  facilities  to 
designate  which  DABS  sensor  will  be  Primary  for  a  particular 
DABS-equipped  aircraft  in  order  to  insure  aircraft-to-ATC  data 
link  connectivity.  Not  every  DABS  sensor  extending  coverage 
into  the  control  boundary  of  an  ATC  facility  will  be 
necessarily  connected  to  that  facility  and  the  coverage  map  may 
designate  an  unconnected  sensor  as  Primary.  It  is  therefore 
necessary  for  the  ATC  facility  controlling  a  DABS  aircraft  to 
be  connected  to  the  sensor  designated  as  Primary  for  that 
aircraft  in  order  to  provide  a  direct  conraunicat ions 
connectivity  between  that  controlling  facility  and  the 
aircraft .When  a  controlled  DABS-equipped  aircraft  is  within 
DABS  sensor ( 8>  coverage,  the  ATC  facility  which  that  sensor  is 
serving  will  provide,  to  the  sensor(s),  information  which 
allows  each  sensor  to  be  appropriately  designated  Primary  or 
Secondary  for  that  particular  DABS  aircraft.  This  information 
will  be  communicated  to  the  sensors  via  an  ACS  Message  (see 
Section  5.2.6).,  and  the  sensor  will  update  the  control  state 
as  indicated. 

P/S  assignment  will  be  based  on  the  control  status  of  a  DABS 
aircraft  in  each  ATC  facility.  Since  only  one  ATC  facility  at 
a  time  has  control  of  an  aircraft,  this  control  status  will  be 
used  as  a  basis  for  the  ATC  facilities  to  designate  the  P/S 
status  of  each  sensor  via  the  DABS  ACS  messages  for  the 
particular  aircraft. 

If  a  DABS  sensor  receives  no  explicit  information  from  any  ATC 
facility  as  to  its  Primary  or  Secondary  status  for  a  given  DABS 
aircraft,  or  if  an  ATC  facility  explicitly  designates  the  DABS 
aircraft  as  Uncontrolled,  the  sensor  will  determine  the 
Primary/Secondary  status  from  the  location  of  the  target 
relative  to  the  adapted  coverage  map,  and  sensor-to-sensor 
coordination  rules. 
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The  information  provided  to  the  sensor  indicating  whether  an 
aircraft  is  controlled  or  uncontrolled  will  also  be  used  by  the 
ATARS  function. 

A  DABS  ACS  Message  is  initiated  by  the  ATC  facility  and  is  sent 
to  the  DABS  sensors  under  any  of  the  following  conditions: 

1.  Whenever  an  ATC  facility  assumes  control  of  a  new  DABS 
aircraft.  In  this  case,  appropriate  ACS  data  will  be  sent 
to  each  DABS  sensor  which  is  supplying  surveillance  data 
on  the  aircraft.  A  Terminal  ATC  facility  can  routinely 
assign  its  sensor  "Primary"  for  all  aircraft  controlled  by 
it . 


2.  Whenever  there  is  a  change  in  control  state  or 
Primary/Secondary  assignment  of  an  aircraft  already  under 
control.  In  this  case,  dissemination  of  the  ACS  data  may 
be  limited  to  those  DABS  sensors  which  have  been  supplying 
surveillance  data  and  are  therefore  affected  by  the 
change.  When  an  aircraft  is  handed  off  to  another 
facility,  the  ATC  facility  relinquishing  control  will  send 
the  appropriate  ACS  assignment  (e.g.,  "Controlled 
Secondary")  to  the  DABS  sensors  providing  surveillance 
data  on  that  aircraft. 


INTEGRATION  OF  DABS  WITH  THE  AIR  TRAFFIC  CONTROL  SYSTEM 


The  implementation  of  DABS  will  require  certain  modifications 
to  the  Terminal  and  En  Route  ATC  systems  in  order  to 
accommodate  the  improvements  and  features  provided  by  DABS 
surveillance,  utilize  the  integral  data  link  capability  for  ATC 
purposes  and  interface  with  the  ATARS  function.  The  following 
sections  provide  descriptions  of  initial  changes  to  the 
existing  Terminal  and  En  Route  ATC  systems  for  interface  with 
the  first  deployment  of  DABS  sensors.  Section  6.1  describes 
the  modified  Automated  Radar  Terminal  System  (ARTS)  and  Section 
6.2  describes  the  basic  modifications  to  the  En  Route  ATC 
System.  The  Terminal  and  En  Route  ATC  systems  have  been 
modified  at  the  National  Aviation  Facilities  Experimental 
Center  (NAFEC)  to  provide  an  experimental  and  developmental 
capability  for  interface  with  DABS.  Changes  to  these  systems 
are  being  evolved  to  develop  and  test  future  DABS/ ATC  software 
and  to  evaluate  DABS-related  activities  (e.g.,  data  link 
applications  and  ATARS).  As  a  result  of  this  ongoing  research 
and  development,  functional  requirements  will  be  defined  and 
the  ATC  system  software  for  DABS  modified  accordingly. 

6.1  Integration  of  DABS  with  the  ARTS  IIIA  System 

6.1.1  Over vi ew 


In  the  present  ARTS  IIIA  system,  existing  terminal  search  and 
beacon  radars  provide  only  analog  data  to  the  ATC  facility. 

Both  the  analog  search  and  beacon  data  are  then  digitized  in 
the  ARTS,  generating  digital  controller  symbols  and 
alphanumeric  data  blocks.  The  search  data  is  digitized  by  the 
RDAS  or  MTD  (depending  on  the  particular  ARTS  configuration). 
The  digital  data  generated  by  the  ARTS  IIIA  processors  is 
superimposed  on  the  analog  (video)  search  and  beacon  data  and 
displayed  to  the  controller  on  the  ARTS  Time-Shared  Display. 

DABS,  however,  is  designed  for  integration  with  an  all-digital 
ATC  system.  The  Terminal  ATC  system  for  implementation  with 
DABS,  therefore,  will  be  based  on  the  Tampa-Sarasota  ARTS 
All-Digital  System  with  exceptions  discussed  in  the  following 
paragraphs.  The  Tampa-Sarasota  System  will  be  modified  to 
provide  for  the  processing  of  surveillance  and  communications 
data  from  a  Terminal  DABS  sensor.  Surveillance  data  processing 
will  differ  significantly  from  the  current  ARTS  IIIA  system: 
the  track/report  correlation,  the  tracking  and  the  flight  data 
association  functions  will  be  distributed  between  the  DABS 
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sensor  and  the  modified  terminal  system.  All  track/datum 
correlation  will  be  performed  by  the  DABS  sensor  while  the 
Terminal  ATC  system  performs  flight  data  association  and 
tracking  (i.e.,  track  position  and  velocity  prediction/ 
update),  utilizing  a  new  tracker  called  the  Thresholded  Alpha 
Beta  Ganma  (TABG)  tracker.  This  tracker  is  designed  to  take 
advantage  of  the  increased  accuracy  of  DABS. 

The  original  ARTS  enhancement  plan  called  for  the  conversion  to 
a  Full  Digital  Display  system  (FDAD)  in  which  the  displays  used 
would  be  equipped  with  vector  generators.  Using  Full  Digital 
Displays  requires  the  digital  generation  of  all  data  presented 
to  the  controller.  With  the  scheduled  implementation  of  DABS, 
the  Full  Digital  Displays  will  not  be  available  in  time  to  be 
used  with  the  early  DABS/ ARTS  facilities.  Therefore,  the 
DABS/ARTS  facilities  at  these  early  sites  will  continue  to  use 
the  presently  available  Time-Shared  Displays.  The  Time-Shared 
Displays  do  not  contain  vector  generators  nor  do  they  have  the 
capability  to  handle  the  total  volume  of  digital  data  (e.g., 
target,  weather  and  map)  which  would  be  required  in  a  full 
digital  mode  of  operation.  Since  DABS  has  been  designed  for  an 
all-digital  system,  there  will  be  no  analog  signals  from  DABS 
to  provide  a  video  display  on  the  Time-Shared  Displays  in 
conjunction  with  the  digital  target  and  track  symbology. 
Therefore,  in  order  to  accommodate  this  interim  period  during 
DABS  implementation,  a  Video  Reconstitutor  will  be  provided  to 
permit  the  continued  use  of  the  Time-Shared  Display  until 
future  replacement  with  Full  Digital  Displays. 

When  DABS  is  integrated  with  an  ARTS  IIIA  system,  the  MTD  (or 
RDAS)  associated  with  the  ARTS  will  be  located  at  the 
transmitter  site.  Digital  search  reports  will  be  transmitted 
directly  from  the  MTD  (or  RDAS)  to  DABS  for  correlation  with 
beacon  reports.  The  digital  surveillance  data,  including 
search  and  beacon  reports  and  weather  messages,  will  be 
transmitted  from  DABS  directly  to  the  ARTS  IIIA  system 
(indicator  site).  The  Video  Reconstitutor  will  be  used  to 
convert  the  digital  target  reports  from  DABS  to  a  representa¬ 
tion  of  the  normal  beacon,  search  and  weather  map  video  signals 
to  drive  the  existing  ARTS  Time-Shared  Displays.  The 
reconstituted  video  data  will  also  be  available  as  a  backup 
mode  during  this  period  in  the  event  of  an  ARTS  computer 
failure . 


The  terminal  system  designed  for  implementation  with  the  Time- 
Shared  Displays  will  hereafter  be  referred  to  as  the  DABS/ARTS 
IIIA  Time-Shared  Display  System  (TSS)*. 

The  principal  DABS/ ARTS  IIIA  TSS  hardware  and  software  com¬ 
ponents  involved  with  the  acquisition,  transmission,  processing 
and  display  of  surveillance  (beacon  and  search)  and  with 
groundlink  communications  data  are  depicted  functionally  in 
Figure  6-1.  This  figure  will  be  referred  to  in  the  following 
sections  which  provide  more  information  on  the  DABS/ARTS  IIIA 
TSS.  Figure  6-2  is  a  functional  diagram  showing  the  subsequent 
integration  of  DABS  with  an  all-digital  terminal  system. 

The  remaining  sections  describe  the  DABS/ARTS  IIIA  TSS  for 
initial  implementation  with  DABS.  Additional  capabilities  will 
be  added  as  requirements  evolve. 

6.1.2  Surveillance  Input  Processing 

All  DABS,  ATCRBS  and  radar-only  targets  will  be  tracked  by  the 
DABS  sensor.  The  DABS/ARTS  IIIA  TSS  will  be  adapted  as  a  non¬ 
correlating  user  by  the  sensor;  therefore,  the  maximum  attempt 
will  be  made  by  DABS  to  perform  report/track  correlation  for 
ATCRBS  and  radar-only  targets.  Correlated  beacon  target 
reports  (beacon  reports  containing  a  DABS  Address  and  ATCRBS 
beacon  reports  containing  a  Surveillance  File  Number  -  SFN) 
will  be  transmitted  to  the  DABS/ARTS  IIIA  TSS  on  the  digital 
surveillance  links  labelled  SI  in  Figure  6-1.  Additionally, 
with  the  integration  of  the  collocated  search  antenna  and  MTD 
(or  RDAS)  at  the  DABS  site,  the  target  reports  transmitted  on 
link  SI  may  indicate  that  the  beacon  reports  are  radar 
reinforced  or  that  the  reports  are  Radar  Substitution,  or  that 
the  reports  are  correlated  MTD  (or  RDAS)  radar-only  reports 
(i.e.,  correlated  with  a  radar-only  track  and  containing  an 
SFN).  Uncorrelated  target  reports  will  be  transmitted  from 
DABS  to  ARTS  for  display  only.  The  digital  target  reports 
transmitted  on  Surveillance  link  SI  will  be  received  at  the 
DABS/ARTS  IIIA  TSS  Communications  Multiplexer  Controller  (CMC) 
and  passed  on  to  the  Data  Processing  Subsystem  (DPS).  All 
DABS,  correlated  ATCRBS  and  correlated  radar  reports  will  be 
tracked  by  the  DABS/ARTS  IIIA  TSS. 


♦DABS/ARTS  IIIA  TSS,  in  this  document,  refers  to  the  modified  ARTS 
IIIA  hardware  and  software  to  process  DABS  sensor  data,  exclusive 
of  the  DABS  sensor. 
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FIGURE  6-1 

DABS/ARTS  IIIA  TIME-SHARED  DISPLAY  SYSTEM 
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FIGURE  6-2 

ALL  DIGITAL  DABS/ARTS  IIIA  SYSTEM 
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Surveillance  processing  in  the  ARTS  IIIA  DPS  will  consist 
primarily  of  track  file  management  and  maintenance  of  proper 
flight  data  association  between  the  correlated  reports 
received  from  DABS  and  the  tracks  maintained  in  the  Central 
Track  Store  of  the  ARTS. 

For  DABS  reports  (both  Beacon  and  Radar  Substitution),  the 
processing  will  consist  simply  of  matching  the  DABS  Address  in 
the  report  with  the  DABS  Address  of  the  respective  DABS  Class 
track  in  ARTS  storage.  If  there  is  no  track  in  storage  with  a 
matching  DABS  Address,  a  new  DABS  track  will  be  initiated. 

For  ATCRBS  and  radar-only  reports,  the  key  element  in  the 
report-to-track  matching  task  will  be  the  SFN.  When  a 
correlated  ATCRBS  or  radar-only  report  is  received  from  DABS, 
the  ARTS  processor  will  attempt  to  match  the  SFN  in  the  report 
with  a  corresponding  SFN  for  a  track  in  storage.  Again,  if  no 
match  is  found,  a  new  track  will  be  initiated  -  ATCRBS  or 
Radar  Class,  corresponding  to  the  report  type.  If  an  SFN 
match  is  found,  several  other  checks  will  be  made,  as 
necessary,  to  further  ensure  that  the  match  is  correct, 
including  a  gross  position  check  between  the  location  of  the 
report  and  the  track.  Reports  which  are  received  as 
correlated  but  otherwise  fail  these  checks,  will  not  be  used 
further,  but  displayed  to  the  controller  as  uncorrelated  data. 

All  correlated  reports  (beacon  and  search)  received  from  DABS 
will  be  tracked.  A  newly  initiated  track  will  be  considered 
"unassociated"  until  such  time  as  it  becomes  associated  with  a 
flight  plan  (either  automatically  or  manually)  or  is  manually 
assigned  an  aircraft  flight  identification.  It  will  then  be 
considered  "associated".  Unassociated  and  associated  tracks 
will  be  displayed  differently  to  the  controller  (the 
associated  track  usually  denotes  controlled  status)  and  will 
be  processed  differently  in  some  respects.  For  example, 
unassociated  tracks  will  be  dropped  more  quickly  than 
associated  tracks  in  the  absence  of  correlated  surveillance 
reports. 

The  DABS/ARTS  IIIA  TSS  software  processes  target  information 
on  a  sector  (11.25  degree)  basis.  This  is  accomplished  by 
using  a  special  Northmark  message,  which  is  generated  once  per 
scan  by  the  sensor,  to  dynamically  compute  the  sensor  scan 
period.  The  computed  scan  period  is  then  divided  into  the  32 
sectors. 
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6.1.3  TABG  Tracker 


When  a  correlated  report  is  matched  to  its  respective  track, 
the  report  and  track  will  be  processed  by  the  TABG  Tracker. 

The  TABG  Tracker  has  been  designed  to  use  the  increased 
accuracy  and  precision  provided  in  the  surveillance  reports 
£rom  DABS  to  produce  track  velocity  estimates  that  are  more 
accurate  than  those  available  from  the  current  ARTS  III 
tracker.  The  TABG  Tracker  will  use  "gamma"  smoothing  (i.e., 
take  acceleration  into  account)  requiring  more  accurate  data 
than  is  available  from  th  present  ATCRBS  sensors  in  order  to 
improve  tracking.  The  TABG  Tracker  will  be  used  in  the  ARTS 
IIIA  TSS  to  improve  long-range  predictions  for  functions 
(e.g.,  Conflict  Alert  and  MSAW)  where  track  velocity 
estimation  accuracy  is  crucial  to  effective  performance. 

The  TABG  Tracker  will  provide  these  functions  with  a  long-term 
smoothed  estimate  of  each  track's  velocity.  Additionally,  it 
will  provide  predicted  positions  for  coasting  tracks.  Since 
the  tracker  will  require  the  use  of  the  highly  accurate 
surveillance  data  from  DABS,  additional  precision  will  be 
maintained  in  the  storage  and  computations  involving 
surveillance  data. 

6.1.4  Communications  Link  Interface 


All  communications  messages  between  the  DABS  sensor  and  the 
DABS/ ARTS  IIIA  TSS  will  be  transmitted  on  the  two-way 
communications  link.  Both  the  receive  and  transmit  channels 
of  the  communications  link  will  interface  with  the  CMC  in  the 
modified  ARTS  IIIA.  Programs  residing  in  the  DABS/ARTS  IIIA 
TSS  will  process  the  communications  messages  in  accordance 
with  the  protocol  and  formats  of  the  Common  ICAO*  Data 
Interchange  Network  (CIDIN).  Processing  for  the  following 
Surveillance-Related  and  Status  Control  type  communications 
messages  will  be  provided  initially:  ATCRBS  ID  Request, 

ATCRBS  ID  Code  Message,  Message  Rejection/Delay  Notice,  Track 
Alert,  Sensor  Status  Message,  Test  Message,  Test  Response 
Message,  the  Aircraft  Control  State  Message  and  the  Altimeter 
Correction  Message.  The  application  of  these  messages  is 
described  in  subsequent  sections. 

The  processing  of  additional  message  types  will  be  included  as 
implementation  progresses  and  new  requirements  (e.g.,  for  data 
link  applications)  evolve. 


*  ICAO  -  International  Civil  Aviation  Organization. 
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6 .1.5  Surveillance-Related  Communications 


The  processing  of  the  following  DABS  Surveillance-Related 
Communications  messages  will  be  provided  for  in  the  DABS/ARTS 
IIIA  TSSs  the  ATCRBS  ID  Request,  sent  from  ATC  to  DABS;  the 
ATCRBS  ID  Code  Message  and  Track  Alert  Message  sent  from  DABS 
to  ATC.  Additionally,  the  Message  Rejection  Notice,  sent  by 
DABS,  will  be  processed  when  it  applies  to  an  ATCRBS  ID 
Request. 

6. 1.5.1  ATCRBS  ID  Code 


Track  storage  for  a  DABS-equipped  aircraft  maintained  in  the 
DABS/ARTS  IIIA  TSS  will  contain  the  aircraft's  DABS  Address 
and  the  respective  Supplied  Beacon  Code.*  The  Supplied  Beacon 
Code  will  be  updated  each  time  an  ATCRBS  ID  Code  Message  is 
received  for  the  track.  The  ATCRBS  ID  Code  Message  will  be 
received  either  "unsolicited"  from  the  DABS  sensor  (see 
Section  3. 3.4.4)  or  in  response  to  an  ATCRBS  ID  Request  (see 
Section  3. 3. 1.4).  This  latter  "Request"  will  be  based  on  a 
controller's  manual  input  action  or  may  be  triggered 
automatically  by  the  DABS/ARTS  IIIA  TSS  software  under  certain 
conditions.  The  Supplied  Beacon  Code  received  as  a  result  of 
a  controller's  action  will  be  displayed  specifically  to  the 
requestor.  Other  display  provisions  relative  to  the  Supplied 
Beacon  Code  are  described  in  Section  6.1.7. 

The  association  between  the  DABS  Address  and  Mode  3/A  code 
provided  in  the  ATCRBS  ID  Code  Message  will  also  be  useful  in 
aiding  Flight  Plan  Processing  as  described  in  Section  6.1.6. 

6. 1.5. 2  Message  Rejection  Notice 

The  DABS/ARTS  IIIA  TSS  will  process  a  Message  Rejection  Notice 
if  it  is  received  in  response  to  an  ATCRBS  ID  Request 
resulting  from  a  Controller's  manual  action.  If  the  Message 
Rejection  Notice  indicates  a  rejection  of  the  ATCRBS  ID 
Request  (the  DABS-equipped  aircraft  is  no  longer  on  the 
sensor’s  roll  call)  or  a  delay  of  the  anticipated  ATCRBS  ID 
Code  Message  (e.g.,  an  air-ground  link  fade  has  occurred), 
then  the  reason  (reject  or  delay)  will  be  displayed  to  the 
requesting  controller  in  the  Message  Readout  Area. 


The  Mode  3/A  received  in  the  ATCRBS  ID  Code  Message  for  the 
respective  DABS-equipped  aircraft  is  referred  to  as  the  Supplied 
Beacon  Code. 


The  contents  of  the  Message  Rejection  Notice  will  not  be 
displayed  if  it  results  from  an  automatically  generated  ATCRBS 
ID  Request. 

6. 1.5. 3  Track  Alert  Message 

If  the  sensor  detects  two  different  aircraft  with  the  same 
DABS  Address  (an  unlikely  event),  it  will  send  a  Track  Alert 
Message  (see  Section  2.8.3).  The  DABS/ARTS  IIIA  TSS  will 
process  the  message  in  order  to  alert  the  controller  to 
initiate  a  procedural  solution  (when  this  condition  occurs, 
the  DABS  sensor  prevents  the  duplicate  tracks  from  being 
placed  on  roll  call  thus  eliminating  the  use  of  data  link). 

The  controller  will  be  notified  of  the  duplicate  DABS  Address 
condition  via  limited  data  blocks  blinked  at  the  coordinates 
(provided  in  the  Track  Alert  Message)  of  each  of  the  aircraft. 
The  displays  will  continue  as  long  as  the  condition  exists  and 
Track  Alert  Messages  are  received;  however,  the  controller  may 
inhibit  the  alert  display. 

6.1.6  Flight  Plan  Processing 

The  DABS/ARTS  IIIA  TSS  will  process  flight  plans  and  amendments 
for  DABS-equipped  aircraft  which  may  contain  either  the  DABS 
Address  or  the  Assigned  Mode  3/A  Code  individually  or  which 
contain  both  the  DABS  Address  and  the  Assigned  Mode  3/A  Code. 
Flight  plans  for  DABS-equipped  aircraft  will  be  processed 
analogously  to  the  way  they  are  processed  in  the  present  ARTS 
IIIA  system  for  ATCRBS-equipped  aircraft.  If  a  DABS  Address 
is  contained  in  a  flight  plan,  a  match  of  the  DABS  Address 
directly  from  a  DABS  beacon  report  will  be  used  to  establish 
an  associated  DABS  Class  track. 

The  flight  plan  for  a  DABS-equipped  aircraft,  however,  will 
not  need  to  contain  a  DABS  Address  (the  flight  plan  then  will 
be  identical  to  those  currently  in  use  for  non-DABS  aircraft). 
In  this  case,  the  use  of  the  ATCRBS  ID  Code  Message  will 
permit  an  unassociated  DABS  track  to  be  associated  with  a 
flight  plan  which  does  not  contain  a  DABS  Address.  The 
"Supplied  Beacon  Code"  (see  Section  6. 1.5.1),  received  in  the 
ATCRBS  ID  Code  Message  for  an  unassociated  DABS  track,  when 
discrete,  will  be  compared  with  the  Assigned  Mode  3/A  Code*  of 
each  unassociated  flight  plan.  When  a  match  is  found, 


*The  Assigned  Mode  3/A  Code  is  usually  automatically  determined 
within  the  ATC  system  and  generally  unchanged  for  major  portions 
of  the  flight.  It  is  communicated  to  the  pilot,  via  voice,  prior 
to  takeoff  and  subsequently  during  the  flight  if  a  code  change  is 
necessary. 
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automatic  track  association  will  be  attempted  using  the  same 
time  and  distance  proximity  checks  as  performed  in  ARTS  IIIA 
for  ATCRBS  Class  track  associations,  but  with  the  Supplied 
Beacon  Code  treated  as  if  it  were  the  ATCRBS  Mode  3/A  Code 
received  in  a  surveillance  report.  If  the  DABS  track 
associates,  the  respective  flight  plan  in  storage  will  be 
updated  with  the  corresponding  DABS  Address. 


By  not  requiring  the  entry  of  a  DABS  Address  in  a  flight  plan, 
external  interface  requirements,  and  thus  implementation,  will 
be  simplified.  Not  imposing  this  constraint  will  permit  the 
DABS/ARTS  IIIA  TSS  to  interface  with  other  facilities  whether 
or  not  they  have  been  modified  to  accommodate  the  DABS 
Address.  It  will  also  alleviate  the  necessity  for  flight 
plans  derived  from  Bulk  Store  to  include  a  DABS  Address.  The 
use  of  the  variable  flight  identification  available  from 
appropriately  equipped  aircraft  via  the  DABS  data  link,  as 
described  in  Section  2.8.2,  will  also  be  included  to  aid 
Flight  Plan  processing  in  future  versions  of  the  DABS/ATC 
Terminal  System. 

6.1.7  Controller  Operational  Inputs  and  Digital  Displays 

The  keyboard  entries  and  digital  displays  for  tracked  ATCRBS- 
equipped  aircraft,  radar-only  tracks,  uncorrelated  ATCRBS 
targets  and  uncorrelated  radar  targets  in  the  DABS/ARTS  IIIA 
TSS  will  be  essentially  similar  to  the  keyboard  entries  and 
digital  displays  in  the  ARTS  All-Digital  System  for 
Tampa-Sarasota.  To  accommodate  DABS,  the  keyboard  entries 
applicable  to  ATCRBS  tracks  will  be  expanded  to  apply  to  DABS 
tracks  as  well.  Also,  the  digital  displays  for  DABS-equipped 
aircraft  will  be  identical  to  the  digital  displays  for 
ATCRBS-equipped  aircraft  with  some  exceptions  to  enable  the 
distinction  of  DABS  targets  and  to  provide  for  the  display  of 
the  DABS  Address.  These  differences  in  keyboard  entries  and 
displays,  related  to  DABS,  are  briefly  described  below: 

1.  Beacon  Readout  Entry 

A  Beacon  Readout  entry  may  be  applied  to  a  DABS  track  as 
well  as  an  ATCRBS  track.  If  the  entry  is  taken  for  an 
unassociated  (uncontrolled)  DABS  track,  a  Limited  Data 
Block  will  be  displayed  as  for  an  ATCRBS  beacon  track 
except  that  the  DABS  Address  will  be  displayed  in  place 
of  the  Mode  3/A  code.  If  the  action  is  applied  to  an 
associated  (controlled)  DABS  track,  the  track's  Aircraft 
Identification  (ACID),  DABS  Address,  Assigned  Mode  3/A 


code  and  Supplied  Mode  3/A  code  will  be  displayed  in  the 
Readout  Area.  A  Beacon  Readout  for  a  DABS  track  will  also 
result  in  the  transmission  of  an  ATCRBS  ID  Request  to  the  DABS 


sensor. 


2.  Entries  Using  Aircraft  Identification 

As  an  option  to  using  the  trackball  to  identify  a  track, 
the  capability  will  exist  to  identify  ATCRBS-equipped 
aircraft  by  use  of  the  four  digit  Mode  3/A  code  in 
certain  keyboard  entries  (e.g.,  Track  Start,  Track  Drop, 
Track  Suspend,  Track  Handoff,  Track  Reposition).  DABS- 
equipped  aircraft,  in  the  modified  system,  may  also  be 
referenced  by  these  keyboard  inputs  except  that  the  DABS 
Address  would  be  used  in  place  of  the  Mode  3/A  code. 

3.  Flight  Data  and  Flight  Plan  Related  Entries 

The  capability  will  be  provided  to  enter  the  DABS  Address 
as  well  as  the  Assigned  Mode  3/A  code  for  these  entries 
also. 

4.  Position  Symbol 

The  position  of  a  DABS  report  which  correlated  with  an 
unassociated  DABS  track  or  a  DABS  report  which  is 
untracked  will  be  uniquely  identified  with  a  hexagon  (O). 
Unlike  ATCRBS  aircraft,  where  special  symbols  distinguish 
between  Mode  C  and  non-Mode  C,  the  O  symbol  will 
indicate  Mode  C. 

The  position  symbol  for  a  Radar  Substitution  report  (DABS 
or  ATCRBS),  whether  uncorrelated  or  correlated  with  an 
unassociated  track,  will  be  identical  to  the  symbol 
displayed  for  a  radar-only  report  in  the  Tampa-Sarasota 
All-Digital  System. 

5.  Mode  3/A  Code 


The  DABS  ARTS  IIIA  TSS  will  provide  the  capability  to 
monitor  the  Mode  3/A  code  of  a  DABS  track  by  using  the 
information  provided  in  the  ATCRBS  ID  Code  Message.  When 
differences  are  detected  between  the  Mode  3/A  code 
received  in  the  ATCRBS  ID  Code  Message  (the  Supplied 
Beacon  Code)  and  the  Mode  3/A  code  assigned  to  the  DABS 
track,  the  controller  will  be  notified  on  the  display. 


The  blinking  display  will  be  the  sane  as  is  provided  in 
the  present  ARTS  IIIA  system  when  the  Mode  3/A  beacon 
code  of  the  datim  correlated  to  a  track  is  not  equal  to 
the  track's  Assigned  Mode  3/A  Code,  except  that  in  the 
DABS/ARTS  IIIA  TSS  the  Supplied  Beacon  Code  will  be 
treated  as  if  it  were  the  Mode  3/A  code  of  a  correlated 
ATCRBS  beacon  report. 

6.  Coast/Suspend  List 

DABS  Class  tracks  in  the  Coast/Suspend  List  will  be 
displayed  identically  to  coasted  or  suspended  discrete 
code  tracks  except  that  a  hexagon  (O)  will  also  be 
displayed  to  denote  a  DABS  track. 

7.  Arrival /Departure  Tabular  List 


DABS  Class  tracks  in  the  Arrival/Departure  List  will  be 
displayed  in  a  manner  similar  to  ATCRBS  tracks  except 
that  the  DABS  Address,  instead  of  the  discrete  Mode  3/A 
beacon  code,  will  be  displayed  along  with  the  ACID. 

8.  Full  Data  Block 

The  Full  Data  Block  (FDB)  for  DABS  and  ATCRBS  tracks  will 
be  identical  to  the  FDB  in  the  Tampa-Sarasota  All-Digital 
System.  However,  if  a  Radar  Substitution  message  is 
correlated  with  a  DABS/ARTS  track,  "RDR"  (radar)  will  be 
displayed  blinking  (as  in  the  present  Tampa-Sarasota 
System)  in  Field  2  of  the  FDB. 

The  video  display  of  target  and  weather  data  processed  through 
the  Video  Reconstitutor  is  described  in  Section  6.1.11. 

6.1.8  Status  and  Control  Message  Processing 

The  Status  and  Control  Messages  (see  Section  5.)  to  be 
processed  initially  by  the  DABS/ARTS  IIIA  TSS  are:  Sensor 
Status  Message,  Test  Message  and  Test  Response  Message, 
Aircraft  Control  State  Message  (DABS  and  ATCRBS)  and  the 
Altimeter  Correction  Message. 

As  DABS  implementation  progresses  and  a  high  degree  of 
overlapping  DABS  coverage  occurs  and  a  number  of  contiguous 
DABS/ATC  facilities  exist,  processing  for  the  Sensor  Failure/ 
Recovery  Message  and  the  ATC  Failure/Recovery  Message  will  be 
included.  The  processing  for  these  messages,  in  conjunction 
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with  the  other  Status  and  Control  Messages,  will  be  determined 
by  tie  requirements  for  an  integrated  DABS/ATC  facility 
failure  and  recovery  mode  processing  capability  interfaced 
with  the  Remote  Maintenance  Monitoring  System  (RMMS). 

6. 1.8.1  Sensor  Status  Message 

A  Sensor  Status  Message  (Section  5.2.1)  will  be  received  once 
each  scan  from  DABS;  the  contents  of  this  message  will  be 
stored  by  the  DABS/ARTS  IIIA  TSS  when  received.  Under  certain 
conditions  (e.g.,  if  a  significant  change  in  DABS  sensor 
status  occurs  or  a  missing  status  message  is  detected),  an 
automatic  printout  displaying  the  appropriate  information  will 
result.  Additionally,  an  operator  at  the  supervisory  position 
will  be  able  to  request  a  printout  of  the  entire  contents  of 
the  last  stored  Sensor  Status  Message. 

6. 1.8.2  Test  and  Test  Response  Message 

A  Test  Message  (Section  5.2.2)  sent  from  the  DABS/ARTS  IIIA 
TSS  to  DABS  will  be  used  as  a  means  of  verifying  proper 
coranunications  operation  between  the  two  systems.  A  Test 
Message  may  be  initiated  by  an  operator's  manual  action  or  it 
may  be  generated  automatically  by  the  software  in  response  to 
certain  conditions  (e.g.,  ARTS  Startover  or  no  messages  sent 
on  the  communications  link  for  an  adapted  period  of  time). 

Upon  receipt  of  the  Test  Message,  the  DABS  sensor  will  repeat 
the  contents  of  the  Test  Data  field  received  in  a  Test 
Response  Message  (Section  5.2.3)  sent  back  to  ARTS.  The 
DABS/ARTS  IIIA  TSS  will  output  the  appropriate  information  to 
the  operator  depending  upon  the  comparison  of  the  data 
received  with  the  data  sent. 

6. 1.8. 3  Aircraft  Control  State  Message 

Processing  related  to  the  Aircraft  Control  State  (ACS)  Message 
(Section  5.2.6)  will  be  a  locally  controlled  option  in  the 
DABS/ARTS  IIIA  TSS.  (If  it  is  not  initially  required  at  a 
particular  facility,  it  may  be  turned  off.)  The  DABS  ACS 
Message  will  indicate  to  the  DABS  sensor  the  control  status 
(Controlled  Primary,  Controlled  Secondary,  Uncontrolled)  of 
each  DABS-equipped  aircraft  tracked  by  the  DABS/ARTS  IIIA 
TSS.  Similarly,  the  ATCRBS  ACS  Message  will  indicate  the 
control  status  (Controlled,  Uncontrolled)  of  each  tracked 
ATCRBS-equipped  aircraft. 
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The  DABS/ARTS  IIIA  TSS  will  determine  and  maintain  the  ACS 
status  for  each  DABS  track  under  its  control.  Basically  when 
a  DABS-equipped  aircraft  (track)  becomes  controlled  by  the 
terminal  facility,  an  ACS  Message  will  be  sent  automatically 
to  the  sensor,  designating  the  respective  DABS  track  as 
Controlled  Primary.  Conversely,  if  a  controlled  DABS  track 
reverts  to  an  uncontrolled  status  after  having  been  controlled 
(e.g.,  track  handed-off  to  another  ATC  facility  or  a  track 
association  is  dropped),  the  DABS/ARTS  IIIA  TSS  will  send  an 
ACS  Message  to  the  sensor  designating  the  respective  DABS 
track  as  Uncontrolled  or  Controlled  Secondary  depending  upon 
the  particular  cause  for  the  change  in  control  state. 

The  DABS/ARTS  IIIA  TSS  will  examine  the  P/S  (Primary/ 

Secondary)  status  bit  (see  Section  5.3)  in  each  DABS  beacon 
message  received  for  a  controlled  DABS  track  to  assure  that 
the  sensor  is  properly  maintaining  the  status  of  Primary  for 
the  respective  DABS-equipped  aircraft.  If  it  is  not  (i.e., 

P/S  Status  bit  set  to  S  instead  of  P),  an  ACS  Message  will  be 
sent  to  the  sensor  to  again  designate  the  respective  DABS 
track  as  Controlled  Primary. 

The  DABS/ARTS  IIIA  TSS  will  also  determine  the  control  status 
for  each  ATCRBS  Class  track  under  its  control.  In  this  case 
only  the  Controlled  and  Uncontrolled  status  is  determined  for 
a  particular  track  and  transmitted  to  the  sensor  along  with 
the  Mode  3/A  Code  and  SPN. 

6, 1.8.4  Altimeter  Correction  Message 

The  Altimeter  Correction  Message  (Section  5.2.7)  will  be  sent 
to  the  DABS  sensor  as  required.  One  altimeter  setting  value, 
which  covers  the  terminal  controlled  airspace  will  be 
maintained  by  the  DABS/ARTS  IIIA  TSS.  An  altitude  correction 
factor,  based  on  this  altimeter  setting  value,  will  be  sent  to 
DABS  in  the  Altimeter  Correction  Message  whenever  the  altimeter 
setting  value  is  changed  or  after  a  communication  link  startup 
or  startover. 

6.1.9  Data  Link  Applications 

The  transmission  of  Minimum  Safe  Altitude  Warning  (MSAW) 
alerts  to  appropriately  equipped  aircraft  is  a  possible  early 
application  of  the  DABS  data  link  in  the  DABS/ARTS  IIIA  TSS. 

A  description  of  this  application  is  contained  in  Section 
3.5.1. 
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In  order  Co  accommodate  ground-air  data  link  applications,  it 
will  be  necessary  for  the  controller  (and  the  ATC  automation 
system)  to  know  whether  or  not  an  aircraft  is  equipped  for 
data  link.  The  extent  of  the  equippage  must  be  known  to  the 
ATC  facility  in  order  to  determine  whether  the  aircraft  is 
capable  of  receiving  a  particular  type  of  message.  This 
information  will  be  provided  in  the  Data  Link  Capability 
Message  (Section  3. 3.4. 3)  which  will  be  sent  by  the  sensor, 
automatically  when  DABS  first  acquires  the  aircraft,  or  in 
response  to  the  Data  Link  Capability  Request  (Section 
3.3. 1.6).  When  data  link  applications  are  provided,  it  will 
also  be  necessary  for  the  DABS/ARTS  IIIA  TSS  to  process 
additional  messages  related  to  the  status  of  the  message 
delivery.  These  messages  are  the  Message  Rejection/Delay 
Notice  (Section  3. 3. 3.1),  Message  Delivery  Notice  (Section 
3. 3.3.2)  and  Message  Cancellation  Request  (Section  3. 3. 1.5)  as 
applied  to  uplink  messages  generated  by  an  ATC  facility.  The 
capability  to  process  these  messages  will  be  included  in 
conjunction  with  the  particular  data  link  application  to  be 
supported.  In  addition,  appropriate  displays  will  be  provided 
to  indicate  to  the  controller  the  status  of  the  message 
delivery  and,  if  applicable,  whether  or  not  standard  voice 
communication  of  the  uplinked  message  is  necessary  in  the 
event  of  a  delay  or  non-delivery. 

6.1.10  Interface  with  the  Automatic  Traffic  Advisory  and 
Resolution  Service  (ATARS) 

A  description  of  this  interface  is  provided  in  Section  4. 

6.1.11  Video  Reconstitutor 

A  separate  digital  surveillance  link,  labeled  S2  on  Figure 
6-1,  will  be  provided  by  the  DABS  sensor  to  transmit 
surveillance  messages  to  the  Video  Reconstitutor.  ATCRBS 
Beacon,  Radar  Substitution,  Radar  Reinforced  Beacon,  Radar- 
only  messages  and  Weather  Map  messages  will  be  transmitted  on 
this  link.  These  messages  will  be  sent  while  corresponding 
messages  are  simultaneously  being  sent  to  the  CMC  on  link  SI. 
The  formats  will  be  identical  to  the  surveillance  formats 
transmitted  to  the  CMC  with  the  exception  of  the  DABS 
surveillance  target  messages  (containing  the  DABS  Address), 
which  are  not  sent.  Instead,  reports  on  DABS  aircraft 
generated  by  the  sensor  will  be  converted  to  an  equivalent 
ATCRBS  beacon  message  prior  to  transmission  to  the  Video 
Reconstitutor .  The  Mode  3/A  code  used  on  this  ATCRBS  message 


will  be  derived  from  the  Mode  3/A  code  setting  of  the 
respective  DABS  transponder.  Converting  the  DABS  Address  to 
the  respective  Mode  3/A  code  will  be  done  to  permit  beacon 
code  filtering  by  the  Video  Reconstitutor  decoder.  The 
procedure  described  elsewhere  in  this  docixnent  for  the  DABS 
sensor  to  acquire,  store  and  update  the  Mode  3/A  code  value  of 
a  corresponding  DABS  Address  will  be  employed  to  maintain  the 
Mode  3 /A  code  current. 

The  Video  Reconstitutor  will  convert  the  digital  target 
reports  to  normal  analog  beacon  (Mode  3/A  and  Mode  C),  search 
and  weather  map  video  signals.  These  signals  will  then  be 
used  to  drive  the  existing  ARTS  Time-Shared  Displays.  The 
Video  Reconstitutor  will  generate  beacon  signals  for  the 
digital  ATCRBS  beacon  messages  received  and  search  video 
signals  for  the  Radar-only,  Radar  Substitution  and  Radar- 
Reinforced  beacon  messages.  The  Video  Reconstitutor  can  be 
procured  with  or  without  a  beacon  decoding  function.  The 
beacon  decoder  will  enable  beacon  code  filtering  for  the 
displayed  video  symbols. 

The  display  symbology  resulting  from  the  reconstituted  video 
will  be  similar  to  the  video  symbology  on  the  current  Time- 
Shared  Display.  However,  the  run  length  of  both  the  beacon 
and  search  symbols  will  be  fixed  to  independently  preset 
(adjustable)  values  which  are  centered  on  the  range  and 
azimuth  values  provided  in  the  digital  surveillance  reports. 
Additionally,  if  the  Video  Reconstitutor  is  purchased  without 
the  decoding  function,  a  single  slash  will  be  displayed  for 
each  detected  bracket  pair  and  an  additional  slash  displayed 
for  SPI. 

Weather  will  be  displayed  as  high  and  low  intensified  areas 
which  encompass  the  respective  weather.  These  areas  will  be 
generated  on  the  basis  of  the  azimuth,  start  and  stop  ranges 
and  the  high/low  intensity  indicator  provided  in  the  received 
digital  weather  message.  It  should  be  noted  that  the 
corresponding  digital  weather  map  messages  transmitted  on 
Surveillance  Link  SI  to  the  CMC  will  be  discarded  by  the 
DABS/ARTS  IIIA  TSS. 

6.1.12  Broad  Band  Backup 


A  backup  mode  can  be  provided  in  the  unlikely  circumstance 
that  there  is  a  failure  in  the  digital  portion  of  the  DABS 
sensor,  or  of  the  links  between  DABS  and  ARTS,  resulting  in  the 


loss  of  digital  data  from  DABS.  In  this  event,  the  failure 
mode  path  shown  in  Figure  6-1  will  be  used  and  a  switch  in  the 
Video  Reconstitutor  will  be  set  to  receive  video  inputs  rather 
than  digital  inputs.  The  DABS  sensor  will  be  switched  to 
operate  as  a  conventional  ATCRBS  interrogator  and  provide  raw 
beacon  video,  based  on  standard  beacon  interrogation  and  reply 
signals.  This  beacon  video  will  be  passed  through  the  Video 
Reconstitutor.  Likewise,  the  search  radar  will  provide  search 
and  map  video  to  the  Reconstitutor.  These  video  signals, 
rather  than  the  reconstituted  digital  signals,  will  then  be 
used  to  drive  the  Time-Shared  Displays. 

6.2  Integration  of  DABS  with  the  En  Route  ATC  System 

6.2.1  Overview 


During  the  time  period  of  the  initial  stages  of  DABS  deploy¬ 
ment,  the  basic  architecture  of  the  En  Route  ATC  System  (i.e., 
using  the  9020  computers)  will  remain  unchanged  from  the 
present.  Initial  integration  of  DABS  with  En  Route  ATC 
facilities  will  therefore  necessitate  modifications  to  the 
current  (9020)  software  system. 

The  following  sections  provide  a  general  description  of  the 
modifications  to  the  En  Route  ATC  facility  software  required 
for  the  initial,  basic  integration  with  DABS.  The  system  will 
be  referred  to,  herein,  as  the  DABS/En  Route  ATC  System. 
Additional  capabilities  will  be  added  as  requirements  are 
defined. 

The  modified  ATC  facility  software  will  have  the  capability  to 
process,  track  and  display  surveillance  data  on  DABS-equipped 
and  ATCRBS-equipped  aircraft  received  from  multiple,  mixed 
DABS  and  ATCRBS  sensors.  Surveillance  data  processing 
(track/datixn  correlation  and  tracking)  and  display  of  data 
derived  from  DABS,  ATCRBS  and  search  target  reports  received 
from  DABS  will  be  similar  to  the  processing  performed  in  the 
current  En  Route  ATC  System  for  target  data  received  from 
ATCRBS  sensors . 

Surveillance-related  communications  will  be  used  to  support 
the  processing  of  DABS  beacon  reports.  Processing  of  communi¬ 
cations  messages  according  to  the  CIDIN  protocol  and  formats 
will  be  accomplished  in  a  DABS  Communications  Front  End 
Processor  (FEP).  The  interface  between  the  FEP  and  the  9020 
computers,  however,  will  be  handled  in  the  DABS/En  Route  ATC 
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system  by  a  communications  protocol  function.  Processing  of 
DABS  data  for  the  Real  Time  Quality  Control  (RTQC)  function 
for  surveillance  will  be  similar  to  the  processing  in  the 
current  system  for  data  originating  from  ATCRBS  sensors. 

Figure  6-3  shows  an  overall  diagram  of  the  DABS/En  Route  ATC 
System  connected  to  DABS  and  ATCRBS  sensors. 

6.2.2  Surveillance  Processing 

The  En  Route  ATC  System  will  be  modified  to  accept,  process 
and  display  surveillance  reports  from  DABS  sensors  in  addition 
to  its  current  capabilities  with  respect  to  processing  surveil¬ 
lance  reports  from  ATCRBS  sensors.  The  surveillance  reports 
from  the  DABS  sensors  which  will  be  processed  are:  DABS 
beacon  reports  derived  from  DABS-equipped  aircraft,  ATCRBS 
beacon  reports  derived  from  ATCRBS-equipped  aircraft,  CD 
Search  reports  and  Radar  Substitution  reports  based  on  CD 
search  data.  If  a  DABS  Terminal  Sensor  is  interfaced  with  the 
DABS/En  Route  ATC  System,  the  capability  will  also  be  provided 
to  process  MTD  (or  RDAS)  Search  Reports  and  Radar  Substitution 
Reports  based  on  MTD  (or  RDAS)  reports.  Surveillance  reports 
received  from  DABS  sensors  will  be  processed  identically  to 
those  received  from  ATCRBS  sensors  except  for  the  differences 
to  accommodate  the  new  message  formats  and  processing  of  DABS 
reports  on  DABS-equipped  aircraft  (i.e.,  containing  a  DABS 
Address  for  identification). 

The  precision  maintained  in  the  present  En  Route  ATC  software 
for  data  storage  and  computations  involving  position  and 
velocity  will  remain  unchanged  in  the  initial  DABS/En  Route 
ATC  System.  This  will  be  done  to  avoid  the  extensive  changes 
to  existing  instructions  and  the  increased  storage  necessary 
to  accommodate  the  additional  precision  provided  in  the 
surveillance  reports  from  DABS.  The  changes  are  not  justified 
initially  because  the  ATC  system  will  be  processing  the 
combined  surveillance  data  from  DABS  and  ATCRBS  sensors. 

Each  DABS  sensor  will  adapt  the  DABS/En  Route  ATC  System  as  a 
correlating  user  for  dissemination  purposes  (i.e.,  the  ATC 
facility  does  its  own  track/report  correlation  and  does  not 
rely  on  the  SFN  in  an  ATCRBS  beacon  or  radar  message  from  DABS 
for  correlation  purposes).  Further,  the  option  to  disseminate 
front-face  (beacon  and  search)  data  only  will  be  selected. 

This  option  will  be  selected  to  avoid  increases  of  the  surveil¬ 
lance  data  load  to  the  DABS/En  Route  ATC  System  from  each  En 
Route  DABS  sensor  with  the  back-to-back  antenna  configuration. 
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FIGURE  6-3 

DABS/EN  ROUTE  ATC  SYSTEM 


6.2.2. 1  ATCRBS  Beacon  Reports  and  Search  Reports 


ATCRBS  beacon  reports  from  DABS  will  be  processed,  correlated 
and  displayed  the  same  as  ATCRBS  beacon  reports  from  ATCRBS 
sensors.  Input  processing,  of  course,  will  recognize  the 
different  message  formats.  Likewise,  search  reports  and  Radar 
Substitution  reports  will  be  correlated,  tracked  and  displayed 
identically  to  the  way  CD  search  reports  received  from  ATCRBS 
sensors  are.  If  a  Terminal  DABS  sensor  is  connected, 
reformatting  to  the  CD  Search  format  will  be  necessary  for  MTD 
and  RDAS  Search  reports  and  Radar  Substitution  reports. 
Additionally,  to  account  for  the  lack  of  run  length 
information  in  target  reports  derived  from  the  MTD  or  RDAS,  an 
equivalent  short/long  run  length  decision,  for  track/report 
correlation  purposes  and  display,  will  be  made  on  the  basis  of 
the  value  of  the  MTD  (or  RDAS)  Confidence  field  (i.e.,  a  high 
Confidence  report  will  equate  to  a  report  with  a  long  run 
length) . 


6. 2. 2. 2  DABS  Beacon  Reports 

A  new  input  procedure  will  be  used  to  accommodate  the 
processing  of  the  24-bit  DABS  Address  in  a  DABS  beacon 
report.  The  key  to  this  procedure  will  be  a  DABS  association 
table  which  will  associate  each  DABS  Address  in  the  DABS/En 
Route  ATC  System  with  its  respective  Supplied  Mode  3/A  ATCRBS 
Code  and  when  tracked,  the  track  identifier.  The  procedure  to 
correlate  DABS  beacon  reports  to  tracks  will  use  this  table. 
The  DABS  association  table  will  also  be  used  to  convert  the 
DABS  Address  to  the  equivalent  Mode  3/A  code  for  display 
(e.g.,  Limited  Data  Block)  and  display  filtering  purposes. 

The  minimum  input  to  start  an  entry  in  the  DABS  association 
table  will  be  a  DABS  beacon  report.  If  it  is  the  first 
message  received  containing  a  given  DABS  Address,  an  entry 
will  be  opened  and  an  ATCRBS  ID  Request  issued  to  the  sensor. 
The  Supplied  Mode  3/A  code  contained  in  the  responding  ATCRBS 
ID  Code  Message  will  then  be  related  to  the  DABS  Address  in 
the  table.  The  Supplied  Code  will  be  updated  and  maintained 
current  whenever  an  ATCRBS  ID  Code  Message  is  received  for  the 
respective  DABS  Address,  whether  requested  by  the  ATC  facility 
(via  an  ATCRBS  ID  Request)  or  received  unsolicited  as  a  result 
of  the  sensor  automatically  triggering  the  "request"  to  the 
DABS-equipped  aircraft. 


6.2.3  Comnuni cations  Link  Interface 


All  communications  messages  transmitted  on  the  two-way  link 
between  each  DABS  sensor  and  the  DABS/En  Route  ATC  System  will 
be  processed  by  the  Front  End  Processor  (FEP)  located  at  the 
ATC  facility.  The  FEP  is  a  DABS  communications  message 
processor  which  will  provide  for  translation  between  the  CIDIN 
protocol  and  the  message  formats  used  on  the  communications 
links,  and  a  FEP/9020  protocol  function  which  will  be  included 
in  the  DABS/En  Route  ATC  software.  The  FEP  concentrates  the 
multiple  DABS  communications  link  interfaces  into  a  single 
interface  with  the  DABS/En  Route  ATC  System.  The  FEP  will 
provide  the  capability  for  addressing  messages  to  the  desired 
DABS  sensor  and  for  identifying  the  source  of  inputs  to  the 
ATC  facility.  Additionally,  the  FEP  will  provide  information 
to  the  DABS/En  Route  ATC  System  regarding  the  status  of  the 
FEP  and  the  status  of  the  communications  links  between  the  FEP 
and  each  DABS  sensor.  The  FEP  interfaces  with  the  General 
Purpose  Input  (GPI)  and  General  Purpose  Output  (GPO)  adapters 
located  in  the  9020  Peripheral  Adapter  Modules  (PAMs).  A 
single  two-way  data  interface  will  be  used  between  the  FEP  and 
the  PAMs. 

The  FEP/9020  Protocol  function  will  provide  the  interface 
between  the  other  application  computer  programs  and  the  FEP. 
This  Protocol  function  will  receive  and  error-check  messages 
from  DABS  which  are  used  by  other  functions  (e.g., 
surveillance  processing,  data  link  applications).  Also,  the 
FEP/9020  Protocol  function  will  format,  for  output  to  the 
sensor,  communications  messages  from  the  appropriate  En  Route 
functional  software.  The  Protocol  function  will  maintain  the 
specific  message  number  sequence  used  for  each  aircraft-sensor 
combination  being  serviced.  A  4-bit  message  number,  the  DABS 
Address  and  the  sensor  address  will  unambiguously  identify 
each  message. 

Initially,  processing  will  be  provided  for  the  following 
coimnuni cations  message  types  transmitted  between  the  sensor 
and  the  DABS/En  Route  ATC  System:  ATCRBS  ID  Request,  ATCRBS 
ID  Code  Message,  Message  Rejection  Notice  applied  to  the 
ATCRBS  ID  Request,  Sensor  Status  Message,  Test  and  Test 
Response  Message,  Track  Alert  Message  and  Altimeter  Correction 
Message.  The  processing  of  these  messages  in  the  DABS/En 
Route  ATC  System  is  briefly  described  in  the  following 
sections.  Processing  for  other  communications  messages  will 
be  included  when  the  requirements  are  defined. 


6.2.4  Surveillance-Related  Communications 


The  surveillance-related  communi cat ions  messages  to  be 
processed  initially  by  the  DABS/En  Route  ATC  System  are  the 
ATCRBS  ID  Request,  ATCRBS  ID  Code  Message  and  the  Track  Alert 
Message.  In  addition,  the  Message  Rejection  Notice  will  be 
processed  when  it  applies  to  an  ATCRBS  ID  Request. 

6.2.4. 1  ATCRBS  ID  Code 


As  described  in  Section  6.2.2,  the  ATCRBS  ID  Request  and  the 
ATCRBS  ID  Code  Message  will  be  used,  for  each  DABS-equipped 
aircraft,  as  a  means  to  maintain  the  association  between  the 
DABS  Address  and  the  Mode  3/A  Code  setting  of  the  DABS 
transponder.  In  addition,  this  association  will  be  required 
to  indicate  that,  for  a  particular  DABS-equipped  aircraft, 

DABS  reports  originating  from  a  DABS  sensor  and  ATCRBS  reports 
originating  from  an  ATCRBS  sensor  are  the  result  of 
interrogating  the  same  aircraft. 

If  an  ATCRBS  ID  Request  is  issued  by  the  DABS/En  Route  ATC 
System,  it  will  time-out  and  transmission  will  be  stopped  if 
no  ATCRBS  ID  Code  Message  is  received.  Transmission  will 
cease  also  if  a  Message  Rejection  Notice  for  the  particular 
request  is  received  from  the  sensor. 

6.2.4. 2  Track  Alert  Message 

Processing  of  the  infrequent  Track  Alert  Message  (Section 
2.8.3)  will  be  similar  to  the  processing  of  the  message  in  the 
DABS/ARTS  IIIA  TSS  (Section  6. 1.5. 3).  Since  a  duplicate  DABS 
Address  condition  results  in  the  sensor(s)  detecting  the 
condition  not  being  able  to  use  the  ground-air  data  link 
(e.g.,  an  ATCRBS  ID  Request  cannot  be  made),  the  controller 
will  be  notified  of  the  situation  via  special  symbology 
displayed  at  the  coordinates  (which  are  provided  in  the  Track 
Alert  Message)  of  each  aircraft.  The  information  will  be 
displayed  for  as  long  as  the  condition  persists  and  Track 
Alert  Messages  are  received;  however,  the  controller  may 
inhibit  the  alert  display. 

6.2.5  Flight  Plan  Processing 

The  DABS/En  Route  ATC  System  will  process  flight  plans  and 
amendments  for  DABS-equipped  aircraft  which  may  contain  either 
the  DABS  Address  or  the  Assigned  Mode  3/A  Code  individually  or 
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which  contain  both  the  DABS  Address  and  the  Assigned  Mode  3/A 
Code.  Flight  plans  (including  automatic  track  initiation)  for 
DABS-equipped  aircraft  will  be  processed  analogously  to  the 
way  they  are  processed  in  the  present  En  Route  ATC  System  for 
ATCRBS-equipped  aircraft. 

If  a  flight  plan  contains  a  DABS  Address  it  will  be  eligible 
for  use  in  automatic  track  initiation  when  a  DABS  beacon 
report  is  received  containing  an  identical  DABS  Address 
(subject  of  course  to  time  and  distance  checks).  If  the 
flight  plan  contains  a  DABS  Address  but  no  Assigned  Mode  3/A 
Code,  automatic  track  initiation  may  be  attempted  also  with  an 
ATCRBS  beacon  report  if  the  Mode  3/A  code  of  the  report  is 
discrete  and  matches  the  "Supplied"  code  corresponding  (via 
the  DABS  association  table)  to  the  DABS  Address  stored  in  the 
flight  plan.  Conversely,  if  the  flight  plan  contains  a 
discrete  Assigned  Mode  3/A  Code  but  no  DABS  Address,  automatic 
track  initiation  may  be  attempted  on  a  DABS  beacon  report  if 
the  "Supplied"  Mode  3/A  Code  associated  with  the  DABS  Address 
(in  the  report)  matches  the  Assigned  Mode  3/A  Code.  As 
mentioned  in  Section  6.1.6,  not  requiring  the  entry  of  a  DABS 
Address  in  a  flight  plan  will  simplify  external  interface 
requirements  (and  implementation)  with  facilities  not  yet 
modified  for  DABS. 

Local  Flight  Data  outputs  (i.e.,  Flight  Strips,  Flight  Plan 
Readouts,  Flight  Plan  Data  Printouts,  Flight  Plan  Data 
Printouts  and  the  Beacon  Code  Update  Message)  will  be  modified 
to  include  the  DABS  Address  as  an  option. 

The  use  of  an  aircraft's  flight  identification  available  from 
appropriately  equipped  aircraft  via  the  DABS  data  link,  as 
described  in  Section  2.8.2,  will  also  be  included  to  aid 
Flight  Plan  processing  in  future  versions  of  the  DABS/En  Route 
ATC  System. 

6.2.6  Controller  Operational  Inputs  and  Displays 

Controller  inputs  and  displays  in  the  DABS/En  Route  ATC  System 
will  be  essentially  identical  to  those  in  the  current  En  Route 
ATC  System.  Since  a  DABS  Address  in  a  DABS  beacon  report  is 
converted  to  a  corresponding  Mode  3/A  report  for  display 
purposes,  the  position  symbols  (correlated  and  uncorrelated) 
for  a  DABS-equipped  aircraft  will  be  identical  to  the  ones  for 
an  ATCRBS-equipped  aircraft.  Likewise,  the  position  symbols 
(correlated  and  uncorrelated)  for  a  Radar  Substitution  report 
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(DABS  or  ATCRBS)  and  a  Radar-only  report  (whether  derived  from 
a  CD,  MTD  or  RDAS) ,  received  from  a  DABS  sensor,  will  be 
identical  to  the  position  symbol  displayed  for  a  CD  search 
message  in  the  present  En  Route  ATC  System. 

The  Full  Data  Block  (FDB)  will  be  identical  to  the  FDB  in  the 
present  system.  The  Limited  Data  Block  (LDB)  for  an 
uncorrelated  DABS  beacon  report  will  also  be  identical  to  the 
LDB  for  an  uncorrelated  ATCRBS  beacon  report.  The  identity 
code  displayed  in  this  first  line  of  the  DABS  LDB,  however, 
will  be  the  "Supplied"  Mode  3/A  code  associated  with  the  DABS 
Address  of  the  uncorrelated  DABS  beacon  report  (see  Section 
6.2.2).  If  there  is  no  Supplied  Code  available  "0000"  will  be 
displayed.  In  either  case  the  altitude  displayed  in  the 
second  line  of  the  LDB  will  be  taken  from  the  DABS  beacon 
report . 

6.2.7  RTQC  Processing 

Initially,  minimal  changes  will  be  made  for  the  DABS/En  Route 
ATC  System  to  process  DABS  data  for  RTQC  purposes.  The  Test 
Message  Monitoring  task  and  the  Radar  Data  Counts  task  will  be 
modified  to  reflect  DABS  surveillance  message  types.  The 
Radar  Site  Reg  istration  task  for  DABS  sensors  will  be  able  to 
use  data  derived  from  DABS-equipped  aircraft  using  the 
corresponding  Mode  3/A  code  (as  described  in  Section  6.2.2). 
The  collimation  task  can,  generally,  be  turned  off  for  DABS 
sites  since  the  radar/beacon  collimation  function  is  performed 
independently  by  the  DABS  Sensor  (see  Section  2. 7. 5.1).  The 
Permanent  Echo  Verification  task  also  need  not  be  done  for  the 
DABS  sensor.  As  s  part  of  the  Performance  Monitoring  task, 
once  each  scan,  each  sensor  compares  the  reported  position  of 
each  CPME  located  around  it  with  the  actual  position  stored  in 
sensor  adaptation.  The  results  of  this  accuracy  check  will  be 
transmitted  to  the  ATC  facility  in  qualitative  form  (i.e., 
Acceptable,  Marginal,  Failed)  in  the  Sensor  Status  Message. 

The  Status  Message  Monitoring  task  will  also  be  modified  to 
process  the  Sensor  Status  Message  recieved  on  the  two-way 
communications  link.  This  is  described  in  the  next  section. 

6.2.8  Status  and  Control  Message  Processing 

The  Status  and  Control  Messages  (see  Section  5.)  to  be 
processed  initially  by  the  DABS/En  Route  ATC  System  will  be 
the  Sensor  Status  Message,  Test  and  Test  Response  Message  and 
the  Altimeter  Correction  Message.  In  addition  certain 
messages  transmitted  between  the  DABS/En  Route  System  and  the 
FEP  to  monitor  communications  status  will  be  processed. 
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As  DABS  implementation  progresses  and  a  high  degree  of 
overlapping  DABS  coverage  occurs  and  a  number  of  contiguous 
DABS/ATC  facilities  exist,  processing  for  the  Sensor 
Failure/Recovery  Message  and  the  ATC  Failure/Recovery  Message 
will  be  included.  The  processing  for  these  messages,  in 
conjunction  with  the  other  Status  and  Control  Messages  will  be 
determined  by  the  requirements  for  an  integrated  DABS/ATC 
facility  failure  and  recovery  mode  processing  capability 
interfaced  with  the  Remote  Maintenance  Monitoring  System 
(RMMS).  Additionally,  when  operational  data  link  functions 
are  added  to  the  DABS/En  Route  ATC  System,  processing  of  the 
Aircraft  Control  State  Message  (see  Section  5.2.6)  will  also 
be  added  as  a  necessary  support  to  that  function. 

6. 2. 8.1  Sensor  Status  Message 

Processing  of  the  Sensor  Status  Message  will  be  identical  to 
the  processing  described  for  the  DABS/ARTS  II1A  TSS  in  Section 
6. 1.8.1. 

6.2. 8.2  Test  and  Test  Response  Message 

Processing  of  the  Test  and  Test  Response  Message  will  be 
identical  to  the  processing  described  for  the  DABS/ARTS  IIIA 
TSS  described  in  Section  6. 1.8. 2. 

6. 2. 8. 3  FEP  Status 

The  FEP  will  send  a  FEP  Status  Message  to  the  DABS  En  Route 
software  whenever  a  change  in  its  status  occurs  or  whenever  a 
change  in  the  communications  link  interface  between  the  FEP 
and  the  sensor  occurs.  This  FEP  Status  Message  will  be 
printed  when  received. 

In  order  to  test  the  interface  between  the  FEP  and  the  En 
Route  system,  the  system  engineer  may  enter  a  FEP  Test 
Message.  Upon  receipt,  the  FEP  will  return  the  contents,  for 
comparison,  in  a  FEP  Test  Response  Message. 

6. 2. 8. 4  Altimeter  Correction  Message 

An  Altimeter  Correction  Message  (Section  5.2.7)  will  be  sent 
to  each  appropriate  DABS  sensor  whenever  an  Altimeter  Setting 
Message  is  entered  into  the  DABS/En  Route  ATC  System.  A 
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number  of  altimeter  reference  points  will  be  adapted  in  each 
DABS  site.  The  DAB8/En  Route  ATC  System  will  transmit  to  the 
respective  DABS  aitea  the  appropriate  altitude  correction  data 
with  respect  to  each  one  of  the  altimeter  reference  points. 

6.2.9  Data  Link  Applications 

The  transmission  of  an  Altitude  Assignment  Clearance 
Confirmation  (triggered  automatically  when  an  Altitude 
Assignment  is  entered  into  the  Bn  Route  ATC  System)  to 
appropriately  equipped  aircraft  is  a  possible  early 
application  of  the  DABS  data  link  in  the  DABS/En  Route  ATC 
System.  A  description  of  this  application  is  provided  in 
Section  3.5.2. 

The  processing  and  display  considerations  regarding  the 
application  of  the  DABS  data  link  functions  in  the  DABS/ARTS 
II IA  TSS  (see  Section  6.1.9)  will  apply  to  the  DABS/En  Route 
ATC  System  as  well. 

6.2.10  Interface  with  the  Automatic  Traffic  Advisory  and 

Resolution  Service  (ATARS)  ~ ~ 


A  description  of  this  interface  is  provided  in  Sections  4. 
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ACRONYMS 

ACID  -  Aircraft  Identity 

ACK  -  Acknowledged 

ACS  -  Aircraft  Control  State 

ADCOM  -  Air  Defense  Command 

ADS  -  All  Digital  System 

ALEC  -  Altitude  Echo 

ARTS  -  Automated  Radar  Terminal  System 

ATARS  -  Automatic  Traffic  Advisory  and  Resolution  Service 

ATC  -  Air  Traffic  Control 

ATCRBS  -  Air  Traffic  Control  Radar  Beacon  System 
BCAS  -  Beacon  Collision  Avoidance  System 

CA  -  Conflict  Alert 

CD  -  Common  Digitizer 

CIDIN  -  Common  International  Data  Interchange  Network 

CMC  -  Communications  Multiplexer  Controller 

CPME  -  Calibration  and  Performance  Monitoring  Equipment 

DABS  -  Discrete  Address  Beacon  System 

DABSEF  -  DABS  Experimental  Facility 

DPS  -  Data  Processing  Subsystem 

ELM  -  Extended  Length  Message 

ESSF  -  En  Route  System  Support  Facility 


FA Z 

— 

Final  Approach  Zone 

FDB 

- 

Full  Data  Block 

FEP 

- 

Front  End  Processor 

GPI 

- 

General  Purpose  Input 

GPO 

- 

General  Purpose  Output 

ICAO 

- 

International  Civil  Aviation  Organization 

ID 

- 

Identification 

IFR 

- 

Instrument  Flight  Rules 

LDB 

- 

Limited  Data  Block 

MA 

- 

Message,  Comm-A 

MB 

- 

Message,  Comm-B 

MC 

- 

Message,  Comm-C 

MD 

- 

Message,  Comm-D 

MSAW 

- 

Minimum  Safe  Altitude  Warning 

MTD 

- 

Moving  Target  Detector 

NAFEC 

- 

National  Aviation  Facilities  Experimental  Center 

PAM 

- 

Peripheral  Adapter  Module 

P/S 

- 

Primary/Secondary 

RDAS 

- 

Radar  Data  Acquisition  System 

RMMS 

- 

Remote  Maintenance  Monitor  System 

RTQC 

- 

Real  Time  Quality  Control 

SFN 

- 

Surveillance  File  Number 

SPI 

- 

Special  Position  Identification 
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SRAP  - 


Sensor  Receiver  and  Processor 


TABG  - 
TATF  - 
TCA  - 
TSS  - 
UM  - 


Thresholded  Alpha  Beta  Gamma 
Terminal  Automation  Test  Facility 
Terminal  Control  Area 
Time-Shared  Display  System 
Utility  Message 
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